DEV Community: Igor Snitkin

Memoization in React and its myths.

Igor Snitkin — Tue, 19 Apr 2022 07:28:39 +0000

Hey kids, how are you? Today we will dive a bit deeper into React and hopefully, I will blow your mind about some of the misconceptions you have. Particularly, we'll be talking about rendering and re-rendering, how we can prevent components from being re-rendered, and whether or not to do it in the first place.

Before we start though, let's align on terminology, so we're on the same page throughout this article:

Mounting/unmounting

We use these terms to describe a moment when components are added to the DOM and subsequently drawn on the screen, or removed from the DOM and screen. It is always rather an expensive operation.

Rendering

The term "rendering", despite common beliefs, has nothing to do with rendering on the screen. Instead, it takes its name from the .render() method of React Component class, basically meaning invocation of the method. In the modern world of functional components, rendering literally means calling your function component. This call will produce a new sub-tree and trigger reconciliation, also known as diffing to determine what has to be updated on the screen, if any at all. This operation is considerably less expensive compared to mounting and React team claims O(n) time complexity where n is the number of nodes within a subtree. The most important takeaway here is that re-rendering will not cause re-mounting.

Lifecycle effects

The main and the most important difference between props and state is that props will be updated on rendering and state on mounting, persisting between re-rendering stages. This means that every time state is dependent on props, lifecycle effect has to be introduced:

const ArticleList = ({ topics }) => {
  // This will be initialized on mount only
  const [articles, setArticles] = React.useState([]);

  // Update list of articles depending on `topics` prop
  React.useEffect(() => {
    fetchArticles(topics)
      .then(data => {
        setArticles(data);
      });
  }, [topics]);
};

Primitive/non-primitive values

Primitive values in React are, well, the primitive values in JavaScript. If you're not sure what are those, this article might be too hardcore for you buddy. Non-primitive are the rest: functions, objects, arrays you name it. We can have primitive/non-primitive props and primitive/non-primitive stateful values.

As a rule of thumb and if there's a choice you should always prefer primitive props to non-primitive props:

// OK
const Address = ({ addressObj }) => {
  /** Display address */
};

// Better
const Address = ({
  streetLine1,
  streetLine2,
  locality,
  postalCode,
  country,
}) => {
  /** Display address */
};

"Wait, what?" I literally hear your brain screaming at me right now. Explaining this will derail us from the scope of this article, so let's just say there are certain optimizations already in place around primitive values, and the best optimization is eliminating the need to be optimized in the first place.

Still not convinced? Ok, consider the two components below and try to guess which one will blow up your call stack (hint: there is only one):

const Primitive = () => {
  const [bool, setBool] = React.useState(false);

  // Now, let's have some fun!
  React.useEffect(() => {
    setBool(false);
  });
};

const NonPrimitive = () => {
  const [arr, setArr] = React.useState([]);

  // Now, let's have even more fun!
  React.useEffect(() => {
    setArr([]);
  });
};

Dependency arrays

Most React hooks will take a callback as the first argument and a dependency array as the second, so the callback is called only if any of the values from the dependency array change. Without any exception, every prop, or any value derived from the prop, used in the callback has to appear in the dependency array. Again, this article is not about dependency arrays and I won't bother explaining why, but I'm pretty sure you can find a good explanation of why dependencies have to be exhausted online. I strongly advise using react-hooks/exhaustive-deps ESLint rule to guard against this rule.

Myths

Cool! Let's start with some of the myths majority of React developers believe in and let's see if you're one of them!

Inline handlers myth

This is super known and the same time super dumb one. It goes something like: You should not inline event handler not to cause extra re-renders:

const handleClick = (e) => { /** handle click */ };

return (
  <>
    {/** BAD */}
    <Button onClick={(e) => { /** handle click */ }} />
    {/** GOOD */}
    <Button onClick={handleClick} />
  </>
);

Of course, this is total BS! The fact that you assign a new function to a variable before passing it as a prop changes absolutely nothing. Not only Button component will re-render, but also a new instance of the function will be passed on every render:

Myth #2: Memoization hooks will prevent components from being re-rendered

So the solution is easy - just wrap your handler in useCallback or useMemo hook, right? Wrong! Even though you will be passing the same memoized instance of the function, it will not prevent the component from being re-rendered. In fact, nothing will stop your regular function component from being re-rendered in the case when the parent is being re-rendered:

Memoization in React

As we just determined, memoization hooks are almost pointless (more about them a bit later), so how do we fix this re-rendering issue. Meet React.memo higher-order component aimed to memoize the component itself and not re-render it in case the same props are provided. So basically, you can trade prop comparison, which is even more performant, to a subtree diffing.

Why is it more performant you can ask. Because a number of props will be less on average compared to a number of nodes in a sub-tree, and because React by default, will use shallow comparison which is an extremely lightweight operation. All you need to do is wrap your component in React.memo:

const Button = React.memo(({ label, handler }) => (
  <button type="button" onClick={handler}>
    {label}
  </button>
));

It's important to understand that React.memo is not a silver bullet and will not save you from re-rendering if different props are passed:

In other words, if you started playing a memoization game you will have to fully commit to it memoizing absolutely every non-primitive prop, otherwise not only it will be pointless, but your app will be less optimized as it will perform both prop comparison and diffing on each re-render.

The same principle abstracts down to React.useMemo hook - every non-primitive value the calculation is dependent on has to be memoized, otherwise your code will actually perform worse:

const Page = () => {
  const { data: users } = useUsers();
  const filteredUsers = users?.filter(filterFn);
  return (
    <>
      {filteredUsers && <RoleList users={filteredUsers} />}
    </>
  );
};

const RoleList = ({ users }) => {
  // Every time new users list provided, group them by role
  const roles = React.useMemo(() => groupBy(users, 'role'), [users]);
};

In the code above, the fact that users from useUsers hook is a stateful value (that persists during re-rendering stages) might give you a false assumption that filteredUsers also will persist, whereas in reality a completely new instance of the array will be created on each render totally obliterating your memoization efforts in RoleList component and making it, in fact, less performant.

Summary

All right, so when should you use memoization in React? That's a good question and, as you might have guessed by now, the answer isn't that simple. But let's summarize a couple of rules that might help you decide:

You should memoize every non-primitive prop causing non-primitive state effects
Generally, any non-primitive value appearing in dependency arrays of React hooks has to be memoized.
You should avoid, if possible, non-primitive props and do not use the default parameters for optional non-primitive props. This will eliminate the need for memoization.
If the parent component has a large number of children, think of the list of items or rows of the table, and each such child updates parent's state - this is a perfect recipe for React.memo usage. In this case all non-primitive props have to be memoized.

Have fun, listen to music, and good luck!

5 JavaScript "tips" that might bite you back.

Igor Snitkin — Fri, 01 Jan 2021 11:25:40 +0000

How many times have you seen articles saying "Do not do that", "This is wrong" or "These tips will make you a pro developer" etc. 😋 I don't know about you, but I've seen enough of those. Don't get me wrong, many of the tips are actually useful and quite valuable, it's not a problem with the implementation itself, rather it's a problem with imitation aka copy/pasting.

Let's see and discuss a couple of those tips. Before we start though, let's determine types of bites, as they would differ by impact:

Readability Bite: will not affect you directly, it will rather bite your teammate who reviews your code.
Type Bite: will bite with using certain types
Syntax Bite: will bite using certain syntactic expression

Alright! Without further ado.

1. Convert to number

This is my favorite, and I have to admit I myself use it all the time. The trick is quite simple, by attaching Unary Plus(+) operator to any value you will force it to be coerced to number:


const strNum = '3645';
const strNaN = 'hi, i am not a number';

typeof +strNum; // "number"
typeof +strNaN; // "number"

+strNum; // 3645
+strNaN; // NaN

This tip is quite light on errors and works pretty much all the time, it's a suggested conversion method by many teams.

`Readability Bite`:

I'm pretty sure, you saw it coming 🙂 It's no-brainer that any developer who doesn't know how unary plus operator works will WTF following code:


function sum(a, b) {
  return +a + +b;
}

Not mentioning the fact that we're all fans of functional programming and this 👆 doesn't align very well with its principles.

`Type Bite`:

Unfortunately this will not work with BigInt, a new numeric data type introduced in 2019.


const veryBigInt = 45n;
+veryBigInt; // TypeError: Cannot convert a BigInt value to a number

Before you start complaining in the comments below, I'm pretty aware that your app will never deal with this type, but we all can agree that functionality that makes no presumptions is more stable.

`Solution`:

One solution that improves readability, is functional and accounts for BigInt:


const veryBigInt = 45n;
const strNum = '3645';
const strNaN = 'hi, i am not a number';

Number(veryBigInt); // 45
Number(strNum); // 3645
Number(strNaN); // NaN

I'm not including conversion to a string here, as from readability point of view it bites the same way:


const ugly = 42 + '';
const good = String(42);
const goodToo = `${42}`;

2. Concatenate arrays

Another extremely popular tip — concatenate arrays using Spread Operator:


const a = [1, 2, 3];
const b = [4, 5, 6];

[...a, ...b]; // [1, 2, 3, 4, 5, 6]

How on Earth this might bite? Well let's say I kinda like this functionality and I want to extract it into function (because functional programming, you know 🤗).

`Type Bite`:

So here's our union function:


function union(a, b) {
  return [...a, ...b];
}

I have one issue right from the start - I want union of any number of arrays, not just two. Any ideas how to refactor it still using the spread operator?

The second issue is that it will include empty cells which depending on situation might not be desirable:


const a = [1, 2, 3];
const b = Array(3);
b.push(4);
union(a, b); // [1, 2, 3, undefined, undefined, undefined, 4]

Finally, we would need to be really really careful with what we're passing as arguments to union:


const a = [1, 2, 3];
const b = null;
const c = 42;
const d = 'hello';

union(a, b); // TypeError: b is not iterable
union(a, c); // TypeError: c is not iterable
union(a, d); // [1, 2, 3, "h", "e", "l", "l", "o"] :/

Putting union aside, this approach forces you to always presume values are arrays, which is pretty bold assumption.

`Solution`:

Let's rewrite our function, so it accounts for all the issues above:


function union(...args) {
  return args.flat();
}

const a = [1, 2, 3];
const b = null;
const c = 42;
const d = 'hello';
const e = Array(3);
e.push(99);

union(a, b, c, d, e); // [1, 2, 3, null, 42, "hello", 99]

I think I hear CS maniacs screaming at me now "Flat iiiss sloooow!" Ok. If your program operates with arrays over 10000 items and you worry about performance, then use .concat():


function union(...args) {
  return [].concat(...args);
}

A bit more performant way, but grabs empty cells. Chances that you will deal with empty cells are super tiny anyway 👍

I guess my message here is that the .concat() method is not obsolete and you shall not treat it this way. Furthermore using functions over operators will make your program just a little bit more stable.

3. Round number using bitwise operators.

Low-level nature of bitwise operators makes them VERY fast and on top of that you have to admit they are quite nerdy and I see how many people can be attracted to them 🤓. Of course any bitwise operator will cause Readability Bite, we won't even discuss it.

Let's get back to "rounding". You might notice that different people will do it with different operators, popular ones are bitwise OR | and double bitwise NOT ~~. In fact you can use all of them:


const third = 33.33;
/* Bitwise AND */
third & -1; // 33

/* Bitwise NOT */
~~third; // 33

/* Bitwise OR */
third | 0; // 33

/* Bitwise XOR */
third ^ 0; // 33

/* Left shift */
third << 0; // 33

/* Right shift */
third >> 0; // 33

/* Zero fill right shift (positive numbers only) */
third >>> 0; // 33

What's going on?!! Too good to be true, isn't it? Well, yes. You are not "rounding" anything you just using bitwise operators to return the same number here and given the fact that bitwise operators can only operate on 32-bit integers this effectively truncates float numbers, because they are not in 32-bit range. Which brings us...

`Syntax Bite`

32-bit integers are integers ranging from -2,147,483,648 to +2,147,483,647. That might sound like a lot, but in fact it's probably the average video count of Justin Bieber on YouTube. As you might guess this won't work outside the range:


const averageBieberViewsCount = 2147483648.475;
averageBieberViewsCount | 0; // -2147483648 🥲
~~averageBieberViewsCount; // -2147483648 🥲

On top of this, it's not rounding in the first place, rather truncating off the fractional part of the number:


const almostOne = 0.9999999;
almostOne | 0; // 0 :/

And finally, this approach has strange relationship with NaN which can cause pretty nasty bugs:


~~NaN; // 0

`Solution`

Just use function built for this:


const third = 33.33;
const averageBieberViewsCount = 2147483648.475;
const almostOne = 0.9999999;

Math.round(third); // 33
Math.round(averageBieberViewsCount); // 2147483648
Math.round(almostOne); // 1
Math.round(NaN); // NaN

4. Rounding with Number.toFixed

While we're on the topic of rounding, let's see one more that is quite popular, especially when dealing with any sort of currency-related numbers:


const number = 100 / 3;
const amount = number.toFixed(2); // "33.33"

Floating numbers in any programming language is a problem, unfortunately it is true for JavaScript and .toFixed() is no exception.

`Syntax Bite`

The problem occurs in the rounding edge case when last digit to be rounded is 5. By rounding rules such case should be rounded up, so:


(1.5).toFixed(0); // 2 👍
(1.25).toFixed(1); // 1.3 👍
(1.725).toFixed(2); // 1.73 👍
/* and so on */

Unfortunately it's not always a case:


(0.15).toFixed(1); // 0.1 👎
(6.55).toFixed(1); // 6.5 👎
(1.605).toFixed(2); // 1.60 👎

As you can see we're not talking about rounding to extreme precisions here, rounding to one or two decimal places is normal everyday routine.

`Solution`

One of the solutions is to use third-party rounding to precision function, like _.round() or similar. Or just write your own such function, it's not a rocket science 🚀:


function round(number, precision = 0) {
  const factor = 10 ** precision;
  const product = Math.round(number * factor * 10) / 10;
  return Math.round(product) / factor;
}

round(0.15, 1); // 0.2 👍
round(6.55, 1); // 6.6 👍
round(1.605, 2); // 1.61 👍

Cool by-product of such function is that you have negative precision rounding aka number of trailing zeros right off the bat:


round(12345, -3); // 12000
round(12345, -2); // 12300
round(12345, -1); // 12350
round(-2025, -1); // -2020

5. Higher-order methods "shortcuts"

Another very popular trick is to use pre-built functions as arguments to higher-order methods (methods that expect function as an argument), it works exceptionally good with .map() and .filter():


const randomStuff = [5, null, false, -3, '65'];

/* Convert to string */
randomStuff.map(String); // ["5", "null", "false", "-3", "65"]

/* Convert to number */
randomStuff.map(Number); // [5, 0, 0, -3, 65]

/* Filter out falsy values */
randomStuff.filter(Boolean); // [5, -3, "65"]

/* Falsy check */
!randomStuff.every(Boolean); // true

You get the point... Super hacky, super cool 😎

`Syntax Bite`

Let's say I need to parse some CSS margin value, pretty reasonable task:


const margin = '12px 15px';
const parsedMargin = margin.split(/\s+/).map(parseInt);

console.log(parsedMargin); // [12, NaN] :/

Every high-order method will invoke a given function passing 3 arguments: element, index, reference to original array. What's happening is on every iteration of method parseInt function is given at least two arguments, and that's exactly how many arguments parseInt expects: string to parse and radix, so we're ending up passing index of the element as radix:


/* Iteration #1 */
parseInt('12px', 0); // Radix 0 is ignored and we get 12

/* Iteration #2 */
parseInt('15px', 1); // Radix 1 doesn't exists and we get NaN

`Solution`

You can always check how many arguments the function you want to use expects using .length, if it's more than 1 then it is probably unsafe to pass this function as an argument and instead we'll need to wrap it:


parseInt.length; // 2

const parsedMargin = margin
  .split(/\s+/)
  .map((margin) => parseInt(margin));

console.log(parsedMargin); // [12, 15] 🎉🎉🎉

Conclusion

Don't just blindly follow whatever is written online, question yourself, research, test, then double research and double test. "It just works" should never be an excuse! If you don't know why it works, then presume it doesn't.

I actually prepared 10 tips for this article, but it appeared to be too long and code heavy for one post, so I might do a follow up soon unless you completely destroy me in the comments. Speaking of comments, feel free to discuss and let me know if you experienced any tips and tricks that have bitten you in the past.

Happy New 2021!

DEV Community: Igor Snitkin

Memoization in React and its myths.

Mounting/unmounting

Rendering

Lifecycle effects

Primitive/non-primitive values

Dependency arrays

Myths

Inline handlers myth

Myth #2: Memoization hooks will prevent components from being re-rendered

Memoization in React

Summary

5 JavaScript "tips" that might bite you back.

1. Convert to number

Readability Bite:

Type Bite:

Solution:

2. Concatenate arrays

Type Bite:

Solution:

3. Round number using bitwise operators.

Syntax Bite

Solution

4. Rounding with Number.toFixed

Syntax Bite

Solution

5. Higher-order methods "shortcuts"

Syntax Bite

Solution

Conclusion

`Readability Bite`:

`Type Bite`:

`Solution`:

`Type Bite`:

`Solution`:

`Syntax Bite`

`Solution`

`Syntax Bite`

`Solution`

`Syntax Bite`

`Solution`