Some people in the React community warn against using arrow functions -- when used incorrectly, they can cause performance issues.
The thing is, arrow functions can make writing code so much easier. So how can I use them without making my components crawl?
Yep, arrow functions are great. They do look nicer, they do take less keystrokes, and they are more fun. But there is a much better reason to use arrow functions…
Arrow functions don’t redefine the value of
this within their function body. This makes it a lot easier to predict their behavior when passed as callbacks, and prevents bugs caused by use of
this within callbacks.
Here’s an example of the type of bug that arrow functions prevent. At first glance, you may expect the button’s background color to change to red when you click it. But if you actually click the button, you’ll find that nothing changes…
null? You can check it by inserting
alert(this) as the first line of
So what’s gone wrong? The problem is that the
this inside those functions has some funny rules. In this case, those rules cause
this to be
Let’s test your understanding with a little quiz: can you explain the reason that
null in the example? Spend a few moments figuring it out, then check your answer below.
this has nothing to do with the class on which it was defined. Instead, it depends on the object that it was called upon.
In terms of
. syntax, this means that if you call
obj.someMethod(), the value of
someMethod will be
obj – regardless of where
someMethod was originally defined! If you just call
someMethod() without using a
this will be
There are two important exceptions:
thiswith a function’s
thisis hard-wired to refer to the value of
thisat the location where the function was defined
None of these exceptions apply in the above example, and you don’t know how
handleClick is called (because it is called within the React’s
button component). As such, you have no idea what
this will be!
My explanation of
this is a bit like high school chemistry; it’s a nice idea but it may give an expert a heart attack.
If all you want to do is use React, it is probably good enough. But otherwise go read the details at MDN.
How’d you go? Don’t worry too much if you’re a little confused;
this is confusing, even for the experts. But there is one important thing that you need to remember:
Once you’ve passed a method as a callback, you have no idea how it will be called, and thus no idea what
this will be.
That is, unless you use an arrow function.
In an arrow function,
this means the same thing within the function body as it does outside of it. Which means that if you use arrow functions within your component’s
render or lifecycle methods, they can use
this.setState with no surprises.
For example, you could fix the above example by replacing the
handleClick callback with an arrow function:
Simple, right? But if you do need help remembering the rule, just remember that arrow functions can’t touch this!
But this old-school classic doesn’t explain why you wouldn’t want to use arrow functions. So let’s continue.
The biggest problem you can have with arrows is that they’re too easy to define. You may find yourself defining functions where don’t actually need them. But why would too many functions be a problem?
Each time your browser executes a
=> statement, it needs to create a new function object. This is an expensive operation. In fact, at the time of writing, calling a function is (very roughly) about 100 times faster than creating it.
Of course, this doesn’t actually become a big problem until you’re building a component which needs super-great performance. The only time I’ve personally found this to be an issue is when rendering very long lists, or very large tables.
So don’t panic about this performance cost. If your component is only rendering once or twice on a page, it won’t be a problem. And if you do start rendering enough elements to feel some lag, you can easily factor out the arrows later.
While arrow functions can slow down a component, the bigger problem is that they can slow down child components. Which isn’t to say that they will slow down child components; they probably won’t. That is, they won’t unless those child components are optimized with
So what’s the problem? Two identical arrow functions are not equal. You can see this for yourself in the example below, where the functions
b are equivalent, but not equal:
Optimizations based on
shouldComponentUpdate work by skipping work when no
props have changed. Learn more at the React docs.
If you use arrow functions within
render, each call to render will create new function objects. If you then pass these functions to child elements via
props, optimizations based on
shouldComponentUpdate will fail (as the arrow function props will change on every render).
You can see this in action in the following example where the
<PropChangeCounter /> component prints the number of times that each of its props have changed. Notice how
constant doesn’t change, while
onChange does. This is because each call to
render creates a new arrow function!
To reiterate, arrow functions do not affect performance. The problems only arise when you re-create the same arrow function on each render. Which means there is a simple fix…
If performance is important for your component, you’ll want to define any arrow functions just once. And the obvious time to do this is when the component loads.
One way of accomplishing this would be to define all your arrow functions in the constructor. Of course, this would become unwieldy for any reasonably complex component, and wouldn’t really have any benefit over simply using Function.prototype.bind.
However, if you’re using Babel (or create-react-app) to build your source, you have another option: setting arrow functions as class fields (or arrow function methods).
For example, you could fix the bug in the first example by redefining
handleClick as an arrow function method:
This example isn't live, as React Armory's live examples don't yet support arrow functions methods. Sorry :-(
This gives you the best of both worlds. You get the improved performance from only defining functions once, but you still get the simple method-like syntax.
A wise man once said that “premature optimization is the root of all evil”. He was probably exaggerating a little bit, but the point he was trying to make is a good one.
You won’t introduce any bugs by using too many arrow functions. You probably will introduce bugs but not using enough.
So to wrap things up, here are the four rules of arrow functions:
If your environment supports arrow function methods, use them for everything.
Don’t use arrow functions for React components; it will make debugging hard.
Do use arrow functions in
render if they’re helpful.
Move functions out of
render (and any methods it calls) if you need to optimize a component’s performance.