Console.log is my friend (yours, too)

I don’t get to use a lot of JavaScript at this point in my new job, so to keep up on my JS skillz I spend some of my weekend time practicing old things or learning new things. Right now I’m learning Node. And while reading some code for a basic Express server, I was reminded of the lovely thing that is console.log.

Here’s the code:


var express = require('express')
var app = express()

var jsonData = {count: 12, message: 'hey'}

app.get('/', function(req, res){
  res.sendFile(__dirname + '/index.html', function(err) {
    if (err) {
      res.status(500).send(err)
    }
  })
})

app.get('/data', function(req, res) {
  res.json(jsonData)
});

var port = 3000
app.listen(port, function(){
  console.log('listening on http://localhost:', port)
})

I can see the code is pulling in Express, that it’s declaring a jsonData variable and assigning an object to it, that the get method will call one of two functions depending on the path that’s being requested, and that the listen method will show me what’s happening on my localhost:3000. And I can see those two get functions are going to use req and res, and I can see what happens with res…but what about req? I figure it’s the request coming in, but I have this need to know what all parts of all things look like, so how do I find out? Put a console.log in those functions, of course! It’s about a gazillion lines of data so I won’t repost it all here but at the very bottom, I see something like this for the first get function when I ask for the root path(‘/’):


route: Route { path: '/', stack: [ [Object] ], methods: { get: true } } }

And something like this for the second get function when I ask for the data path (‘/data’):


route: Route { path: '/data', stack: [ [Object] ], methods: { get: true } } }

Doing things like this helps the code make more sense in my brain. While I understood that the functions were taking in requests and returning responses, now I can see what the requests actually look like and I can see how the functions are seeing the path. Yay!

Flex-basis, flex-grow, & flex-shrink

Flex-basis, flex-grow, and flex-shrink are three Flexbox properties that can make things easier when dealing with responsive design. So what’s the difference between them? Let’s take a look at some code and find out!

Flex-basis is how much space we want our element taking up in an ideal world, before we start addressing extra space or less space. So in this instance, we want each of these divs to be 100px wide.

.div1 {
  flex-basis: 100px;
}

.div2 {
  flex-basis: 100px;
}

Now, when we’re viewing these two divs in any browser wider than 200px, there’s going to be some leftover whitespace. Flex-grow helps us decide how we want to divvy up any extra whitespace between our elements. So, as whitespace expands, div1 will take up twice as much of it as div2:

.div1 {
  flex-basis: 100px;
  flex-grow: 2;
}

.div2 {
  flex-basis: 100px;
  flex-grow: 1;
}

Flex-shrink helps us decide how we want our elements to behave as space decreases. In this case, we want div2 to shrink twice as much as div1:

.div1 {
  flex-basis: 100px;
  flex-grow: 2;
  flex-shrink: 1;
}

.div2 {
  flex-basis: 100px;
  flex-grow: 1;
  flex-shrink: 2;
}

To make it much more concise, we can re-write our code like this:

.div1 {
  flex: 2 1 100px;
}

.div2 {
  flex: 1 2 100px;
}

I hope that helps make sense of these three properties. If you want to learn more about Flexbox, you can’t go wrong with Wes Bos’ free series.

On object manipulation in JavaScript

Honesty is important to me, even when it means coming clean about things I struggle with. Today, I confess that I struggle with comprehending object manipulation in JavaScript. Earlier this morning I was pairing with a friend on some katas in Code Wars, and I was struggling to understand what was happening with this code:

let staff = {
  tim: 'finance',
  jim: 'accounts',
  randy: 'canteen'
}

function boredom(staff) {
  var map = {
    accounts: 1,
    finance: 2,
    canteen: 10
 }

  var score = Object.keys(staff).reduce((a, b) => {
    return a + map[staff[b]]
  }, 0)

  return score <= 13 ? 'kill me now' : 'party time!!'
}

As you can see, boredom is taking in the staff object, where it wants to match up the staff values with the corresponding numbers in the map object, then tally the numbers to produce a score and return that score’s relevant string. So theoretically I understood all that, but not this specific part:

map[staff[b]]

My brain was reading it like this…

map.staff.b

…which is sort of right, but also why I was getting confused.
I mean, map and staff are two separate objects, not connected in any way, so how is that working? Let’s walk through it! And by let’s I mean me, so I can solidify my understanding 🙂

Alright, so the first time through, a is 0 and b is ‘tim.’ Which means map[staff[b]] is basically map['tim']. And what’s Tim’s value? It’s finance. Since Tim’s value is ‘finance,’ map['tim'] is basically map.finance. And what is map.finance? That’s right, it’s 2! So the first time through, 2 gets added to 0, and on the next time through 2 becomes a, and b is now ‘jim,’ and on and on until the numbers are reduced down and boredom spits out how you feel about your office’s fun level.

Check out the reduce method on MDN.

Find out more about objects in Eloquent JavaScript.

And don’t forget, you can walk through code step-by-step on this site.

Let’s learn about objects and this

No really, let’s. Because I’ve learned this already, but I need all the reviewing I can get. This should take 6-8 hours.

First, watch these videos by one of my very favorite JS resources, Mattias P. Johansson. (And later on, find time to watch all his other videos – he’s highly entertaining, very human, and also super nice on social media.) No need to code along.

Then read chapters 1 and 2 of this book by another one of my favorites, Kyle Simpson. You may, like me, feel both dumber and smarter after reading Kyle’s material, but that’s okay – he knows his stuff and it’ll be worth it. I like to code along with the examples Kyle provides, but you don’t have to.

Now, code along with Mary while she makes a fun little game. She moves fast and you may have to stop the video every few minutes to catch up. After you’ve got all your code written and working, watch the video again while adding comments to your code about what every single thing is and what it’s doing. You’ll learn more in this second run-through than you could catch in the first, trust me.

There, now you’re an expert! Okay, not really – but you learned some stuff, right? BOOM.