An under-appreciated concept in JavaScript is how objects and functions are , and that directly impacts React performance. If you were to create two functions that are completely identical, they are still not equal. Try for yourself: references But check out the difference if you assign a variable to an already-existing function: Objects work the same way. If you have experience in other languages, you may be familiar with . What is happening here is that each time you create an object, you are allocating some amount of memory on the device. When I said that , I have created a chunk of bytes in the user’s RAM that is dedicated specifically to . It is fair to imagine as an address that contains where in RAM its key-value pairs are located. When I said , I created a chunk of bytes in the user’s RAM that is dedicated specifically to . Does the of match the address of ? No. That is why the equality check for the two variables does not pass. Their key-value pairs may be exactly the same, but their addresses in memory are different, and that is what is being compared. pointers object1 = {} object1 object1 object2 = {} different object2 address object1 object2 When I assigned , I am assigning the value of to be the of . It is not a object. It is that same location in memory. You can verify this like so: object3 = object1 object3 address object1 new In this example, I created an object in memory and assigned it to . I then assigned to that same address in memory. By mutating , I have changed the value at that location in memory, meaning . , which still points to that location in memory, now has a changed value. object1 object3 object3 all other references to that location in memory change as well object1 This is a very common error for junior developers to make, and likely warrants an in-depth tutorial of its own; but this particular tutorial is about React performance, which may be compromised even by developers with more seniority who have simply not considered the implications of variable references. What does this have to do with React? React has an intelligent way of saving processing time to boost performance: If a component’s props and state have not changed, then the output of must not have changed either. Clearly, if all things are equal, nothing has changed. If nothing has changed, must return the same output, so let’s not bother executing it. This is what makes React . It only renders as needed. render render fast React determines if its props and state are equal the same way JavaScript does — by simply comparing them with the operator. React shallow or deep compare objects to determine if they are equal. Shallow comparison is a term used to describe comparing each key-value pair of an object, as opposed to comparing the memory address. Deep comparison is going one step further and, if any of the values in the key-value pair are also objects, comparing those key-value pairs as well, ad nauseum. React does neither: it merely checks if the are the same. == does not references If you were to change a component’s prop from to another object , React will re-render, because those two objects do not reference the same location in memory. If you were to change a component’s prop from (from above) to , React would re-render, because those two objects the same reference. { x: 1 } { x: 1 } object1 object3 not are In JavaScript, functions are handled the same way. If React receives an identical function with a different memory address, it will re-render. If React receives the same function reference, it will not. This is an unfortunately common scenario I come across during code review: This is a pretty straightforward component. There’s a button, and when it is clicked, it alerts. Instructions tell you whether or not you should click it, which is controlled by the or prop of . do={true} do={false} SomeComponent What happens here is that every time is re-rendered (such as toggling from true to false), is re-rendered too! The handler, despite being exactly the same, is being every render call. Each render, a new function is created (because it is created in the render function) in memory, a new reference to a new address in memory is passed to , and the component is re-rendered, despite absolutely nothing having changed in its output. SomeComponent do Button onClick created <Button /> Button The Fix If your function does not depend on your component (no contexts), you can define it outside of the component. All instances of your component will use the same function reference, since the function is identical in all cases. this In contrast to the previous example, remains the same reference to the same location in memory during every . therefore has to re-render. createAlertBox render Button never While is likely a small, quick-to-render component, you may see these inline definitions on large, complex, slow-to-render components, and it can really bog down your React application. It is good practice to simply never define these functions inside the render method. Button If your function depend on your component such that you cannot define it outside the component, you can pass a method of your component as the event handler: does In this case, each instance of has a different alert box. The click event listener for needs to be unique to . By passing the method, it does not matter if re-renders. It doesn’t even matter if the prop changes! The address in memory of does not change, meaning does not have to re-render, and you save processing time and improve rendering speed of your application. SomeComponent Button SomeComponent createAlertBox SomeComponent message createAlertBox Button But what if my functions are dynamic? The Fix (Advanced) I wrote the following examples off the top of my head as a way to repeatedly reference the same function in memory. These examples are meant to make comprehension of references easy. While I would recommend reading this section for the purpose of comprehending references, I would also suggest following it up with . A few readers have generously contributed which take into account cache invalidation and React’s built-in memory management. Author’s Note: this comments section better implementations There is a very common use case that you have a lot of unique, dynamic event listeners in a single component, such as when mapping an array. In this case, you have a variable number of buttons, making a variable number of event listeners, each with a unique function that you cannot possibly know what is when creating your . How can you possible solve this conundrum? SomeComponent Enter , or what may be easier to refer to as simply, . For each unique value, create and cache a function; for all future references to that unique value, return the previously cached function. memoization caching This is how I would implement the above example. Each item in the array is passed through the method. Said method will, the first time it is called with a value, a function unique to that value, then return it. All future calls to that method with that value will not create a new function; instead, it will return the reference to the previously created function in memory. getClickHandler create As a result, re-rendering will not cause to re-render. Similarly, adding items to the prop will create event listeners for each button dynamically. SomeComponent Button list You may need to use your own cleverness for generating unique identifiers for each handler when they are determined by more than one variable, but it is not much harder than simply generating a unique prop for each JSX object in the mapped result. key A word of warning for using the as the identifier: You may get the wrong result if the list changes order or removes items. When your array changes from to just and you have cached your event listener as , you will find that when you users click the now-index-0 button for pizza that it alerts . This is the same reason React advises against using array indices for key props. index [ 'soda', 'pizza' ] [ 'pizza' ] listeners[0] = () => alert('soda') soda Conclusion If you liked this article, feel free to give it a clap or two. It’s quick, it’s easy, and it’s free! If you have any questions or relevant great advice, please leave them in the comments below. To read more of my columns, you may follow me on and , or . LinkedIn Twitter check out my portfolio on CharlesStover.com
