Arrow functions, context and why they're so important in React.js

An unintuitive concept, but these are fundamentally different 

<button onClick={this.runFunction}//>
//NOT THE SAME
<button onClick={() => this.runFunction()}//>

Try it out yourself later in a component, where this.runFunction uses this.setState. The first will throw an error. The other will not. Theres a short explanation and a long one. To someone who has no idea why these two are different, I think a long explanation is in order.

function and its this play by its own rules

The defintion of context in a function does not obey lexical scoping unless you tell it to. If you give it no declarations, it assumes this is the window object.

Strict declaration of context 

this.myFunction // 'this' is my context, where my 'this' resulting declaration will obey lexical scoping

function ConstructorExample() {

  this.testAnonThis = function() { //this.testThis binds this function to my constructor's context
    let anonThis = (function(){
      return this
    })() //anonymous function. THIS HAS NO BINDING. Remember, not lexically scoped.
    console.log(`anonThis is the window object?: ${window === anonThis}`)
  }
}
new ConstructorExample().testAnonThis()
//anonThis is the window object?: true

Why do function-based anonymous functions have this === window?

JavaScript assigns context very late. As mentioned before, the assignment of this in an anonymous function does not obey lexical scoping. Some see it as a strength, because you can reuse functions and keep things lean, while others call it unintuitive and flawed by design.

Arrow functions have no this

So important to understand, that it hurts. I need to explicitly state it:

functions assigned using function have a context automatically asigned: (this). Arrow function do not have a this

So how does this apply to React.js?

10 years later, I'm going to explain that original statement. 

<button onClick={this.runFunction}/>
This is assigned using function, which has its own context. 
  <button onClick={()=> this.runFunction()}/>
Assigned as an arrow function, which has a this that is inherited from the React component class.

My personal opinion: Just use arrow functions, all the time.

It's important to understand fundamentals. But at the end of the day, the ECMAScript team introduced arrow functions for a very good reason: They make so much sense.

In fact, they make sense to the point where you don't even have to know what's going on to use them flawlessly. In my opinion: an incredible strength, but a minor detriment. The future will consist of developers that don't understand fundamentals, such as myself, from 3 months ago. But you will never run into context issues if your event handlers are arrow functions.

Yes, I know I didn't explain how to fix the function-based assignment

Brainless answer: use bind. 

<button onClick={this.runFunction.bind(this)}/> //proper scope

If I somehow not been talking to myself for the past 7 blog posts and any viewers want to understand this topic, feel free to leave me a comment and I'll go over bind, call, and apply.

Comments

Post a Comment

Popular posts from this blog

Contrasting var and ES6s new declarations: let and const

let and const are two new declaration types in JavaScript, which have the ability to completely replace var declaration. To use them effectively, and understand why they can be a direct replacement, it's important to understand how they work. var is function scoped. It is hoisted and initialized at the top var , regardless of where it is assigned, will become declared and initialized at the beginning of the function. This means that any variable you declare will be available everywhere inside the function. This process is referred to as hoisting. Hoisted variables with var are declared and initialized at the top of the function, but have no value All variables that are declared and initialized with var are initialized as undefined . They have no value until you reach the line of code that assigns it a value. const undefinedConsoleLog = _ => { console.log(sadlyUndefined) //undefined var sadlyUndefined = 'declared by var, und
Read more

Modularity vs. Abstraction. Which is More Important?

Coupling? Bad. Coupling is the enemy of modularity. Coupling creates the need to understand the inner workings (implementation details) of multiple functions/objects/entities in order to understand what the code is doing. Abstractions? Good. Abstractions are a natural concept in this world. I do not need to understand how a car works in order to drive mine. In programming, being able to use functions and components without understanding their inner workings is a sign of well-designed abstraction. A clear and tight interface that is easy to work with is a sign of good code. Good modularity with bad abstractions? Could be better. It's not fun to read, but at least you know where everything is. This tends to create large components and classes, but I see it as the lesser of two possible evils. Bad modularity with good abstractions? The worst spaghetti possibl
Read more

Unit testable components pt.3: Testing components

My approach to component testing There are multiple resources that show how to test components. When you read between the lines, they are actually describing their philosophy on how a component should be tested. My tests are basic and practical because my components are dumb My components have the following properties No api calls Small encapsulated components Minimal Redux actions As a consequence, my tests have the following principles Shallow mount component directly. Ignore Redux's connect higher order function (HOF) in test
Read more