When I first read that javascript was getting a arrow function shortcut, I was happy. Like this kind of happy:

Seriously. So happy. Check out the code below and tell me it doesn’t feel great.

1
2
3
4
5
var times_2 = [1,2,3,4].map((num) => num * 2);

times_2.forEach((num) => {
console.log(num);
});

Pretty, great, right? The arrow function shortcut seemed like a perfect port of the lambda syntax from C#. Buuuut it’s not. Like, not at all.

When you use the ES6 arrow function, it creates a lexical scope. Lexical (also called static) scoped functions are functions where the this context is set to it’s parent, and cannot be altered. This means that the examples above would translate (roughly) to this JavaScript:

1
2
3
4
5
6
7
var times_2 = [1,2,3,4].map(function(num) {
return num * 2
}.bind(this));

times_2.forEach(function(num) {
console.log(num);
}.bind(this));

Now in these two examples the scoping isn’t an issue. In fact in a lot of cases you won’t care about the => operator creating a static scope. But it’s really easy to forget, especially when everyone on the internet just refers to this thing as the “ES6 arrow function”.

For real? “Arrow function” makes it sound like this isn’t doing anything other than dropping a function into my code. It’s a bad name and it should feel bad.

To me, the better name for this is the “static scope operator”. Yeah it’s longer, fite me. Authors Note: don’t really fight me, I’m overly squishy and bruise easily. Let’s grab a drink of your preference and talk about movies or comics instead.

Using a name that doesn’t call out that this operator creates a static scope seems like a bad idea to me. Scope is an incredibly tricky thing to understand in JavaScript, so to me it should be very obvious when we are about to muck around with it.

This obfuscation of the static scope operators intent often leads to code that is harder to understand. For example, what if we wanted to create an action handler for a React component?

1
2
3
4
5
6
7
8
9
class MyComponent extends React.Component {
onLinkClick = () => {
// do stuff
}

render() {
return <a onClick={this.onLinkClick}>Clicky</a>;
}
}

The low number of lines of code here is a plus, but that onLinkClick property is hard to grok at first glance. When we write code, we’re writing code for the people that we work with now and in the future who will maintain our code. Code is for coworkers.

Let’s try cleaning this up.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import _ from 'lodash';

class MyComponent extends React.Component {
constructor() {
_.bindAll(this, 'onLinkClick');
}

onLinkClick() {
// do stuff
}

render() {
return <a onClick={this.onLinkClick}>Clicky</a>;
}
}

To me this second example is much easier to read and is clearer about how the code functions. The scope binding is clear, and explicit.

So when do I use a static scope operator? Usually in simple callbacks, like map/reduce or a one line promise handler. I don’t see the value of using => for every function by default, especially not in the class definition like above. But if you disagree, cool. I’d love to hear your points so post a comment, twit me on twitter (@codeimpossible), or chat with me at a conference.

My intention here wasn’t to make you feel bad for using static scope operators (yep, I’m going to keep calling it that). I do hope that this post made you think more about the abstractions you use and make you ask yourself if they making your code easier to read, maintain, and test, or if they are just saving you a few keystrokes.

Comment and share

In January I was lucky enough to participate in a project review session for General Assembly a programmer bootcamp here in Austin, TX. I was one of three professional software devs brought in to provide feedback on the students’ projects. The feedback can be on anything, from how they approached the UX, their data models, how they used git… anything.

During each presentation each team had a set of topics that they had to talk about, one of them being “rose, bud, thorn” or “what was great about this project/experience”, “what will you take on to your next project(s)”, and “what sucked”.

One team of students began a demo of their search filters for a recipe site they had built. It had a great amazon-esque checkbox filter system where you could pick recipe ingredients to filter the list of recipes on the site. It worked really well.

For their “what sucked” part, one of the team members brought up the code for the checkbox filtering and showed how it worked. There was a collection of around twenty if statements that controlled what happened when one of the recipe filters was chosen.

Basically it looked something like this, just 20x as much:

1
2
3
4
5
6
7
$('checkbox1').on('change', function() {
if ($(this).is(':checked')) {
$('form #hidden1').val($(this).val());
} else {
$('form #hidden1').val('');
}
});

So for each checkbox there was a matching hidden field in a form so the selected search filters could be sent to the server and the search could be carried out. A truly righteous hack, if I may say so.

When the rest of the reviewers and I saw this we kinda chuckled a bit - which to be honest, probably wasn’t the best response - but I explained that we were all chuckling because hacks are a common thing in software development and we’d all done hacks like that (or in worse) to make something work to meet a deadline. It’s a fact of life. And it’s a friggin’ important one too.

We should create hacks more often. Don’t kill yourself for 2-3 hours to try to find the best/most correct way to do something immediately. If you meet resistance, do the simplest thing that could possibly work - make a hack - and move on. Come back to it - or even better get someone to pair or code review what you’ve done - and refactor it when you know the better way to do it. Bad code is… well, yeah, bad… but it’s also super important since it helps us grow and become better.

You won’t forget your hacks easily. They’ll stay with you for a while; they will keep you up at night. In fact, one night, you’ll probably refactor them into as few lines of code as possible.

And one day you’ll come back to those hacks, years from now and chuckle too.

Comment and share

I decided to start 2016 off a bit differently. Normally I’d write a recap post for 2015 listing all the things I didn’t do, and how I was going to finally do them this year. Because this year is totally different than all the others before it.

Right. So, new year, new way of doing things. First, the blog. It hasn’t gotten any love in pretty much a year, so I’m here kicking the dust off of it, fighting away all of the spiders and rodents that have nested in the past 12 months. New platform, it’s running on hexo a static site generator that runs on node.

Why Node? Well, I got tired of dealing with the hassle of my jekyll powered blog, sure it ran, but everytime I wanted to go back to it I had to remember to install ruby, python, jekyll, pygments and I hadn’t used any of those in a super long time. So just getting my blog viewable on my laptop was a nightmare, never mind trying to get it to run on my desktop (which is windows based). Forget it.

As part of the transition, I decided to not port a lot of my older posts. This is mostly just because I’m too lazy to grind through the changes necessary to get the posts to work with the new blog platform. I moved over 2 of my most popular posts, if you’re looking for other posts, check out the git repo.

If you’re suuuuper interested in having me move a post over for whatever reason then open an issue on github and I’ll do it.

So, new blog. What else?

Well we’re going to go back to this whole living healthy thing. It worked well in 2012 when I was on my way to getting married - I was at an all-time low of 235lbs. I’d like to get down there again. I’ve spent the last 2 years hovering around 270-280 and it’s not enjoyable. It’s that awkward part of being a big person where your lower half of your body is still holding out hope that the top half will go back to being thinner. It is awful and frustrating and I pretty much hate myself everyday.

More Writing. Yep. Twitter - and my own self-doubt - have ruined my writing ability. It’s time to get back into this and churn some stuff out that I can be happy with, and maybe (hopefully) write some stuff that other people find valuable too.

New year, new sheriff in town. Time will tell how well the new rule goes.

Comment and share

  • page 1 of 1

Jared Barboza

dev @Hudl. I like javascript, cats and video games. I’m an adult, opinions here are mine.


Software Developer, npm installer


Austin, Texas