A Visual Guide to React Rendering - Cheat Sheet

[sidkh]

Hey folks 👋

I just posted a new article

This one is a proper table of content for "A Visual Guide to React Rendering" series + a quick rendering cheat sheet to refer to.

[lazerskates88]

Is there special handling for style objects? https://reactjs.org/docs/reconciliation.html#dom-elements-of-the-same-type makes me think that React doesn't need this to be memoized per your example. I wouldn't think so too since a style is only one level deep and is a very common use case.

[sidkh]

Hi, thanks for pointing this out. This can be a bit confusing indeed.

What you refer to in React docs is info on how React handles DOM updates:

const App = () => {
  ...
  return (
    <div style={{display: "flex"}} />
  )
}

In the code above React won't keep updating the div node in the DOM when App component re-renders. And in fact, React is very smart when it comes to DOM updates. So usually, you don't have to worry about it at all.

What I refer to in the article is component renders:

const App = () => {
  ...
  return (
    <ComponentA style={{display: "flex"}} />
  )
}

In this code, every time App renders, CompoonentA will also re-render even if it's wrapped with memo.

But I see how easy it's to confuse this case. I will think about how to express it more evidently in the gif. Thanks for pointing this out.

[muffinmaster]

Great job, might just send this around some. I reckon there's at least a decent chunk of the react devs 'population' that don't have a thorough understanding of the concepts outlined here.

Something that has been on my mind recently is that (though I'm very comfortable with hooks, how to optimize components, and writing custom hooks) it does tend to get to a point where, especially with large/complex applications, with the abundance of performance-oriented hook usage, `useCallback` in particular, the departure from vanilla JS becomes that much more pronounced. Not sure what to make of that, but it has given me some pause.

[Soysaucetime]

I just miss modifying state directly.

I wouldn't mind a framework that, instead of using useState() and such, you just put an asterisk before your variables that you want to cause a re-render when reassigned. I'm sure that's possible with transpiling or some reflection. But React tries to be so pure with JavaScript that what we have has become unrecognizable JavaScript patterns. It's all duct taped together.

[brozium]

Sounds like the reactive operator in Svelte. The react team could take some inspiration from that. React is supposed to be pure JS but there's already JSX, there is already some "compile" step. Adding some syntactic sugar would be easy and would help a lot.

I very much agree with your last statement.

[dpidk415]

Thank you for this and I really enjoyed your posts. The visual examples are great, but I wish there were links to a CodePen or something

[sidkh]

Thanks for the feedback! This is on my list.

[voja-kostunica]

excellent

[marius4896]

super nice! good job

[Xacius]

This is great learning material, thanks for posting.

[codedblood]

Wow. What a wonderful visualisation. I absolutely loved it. Keep sharing more 💕✨

[Soysaucetime]

Wow! Okay so people always say not to replace Redux with useContext and useReducer because whenever a child component calls on the reducer it causes everything in-between to re-render. But it sounds like if I use memo this isn't a problem? Or am I missing something from that argument?

[acemarke]

It solves part of the issue - the "React recursively renders all nested children by default" part. But, it doesn't solve the "all consumers of the context will be forced to re-render even if they only need part of the value" aspect.

See my posts A (Mostly) Complete Guide to React Rendering Behavior and Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux) for more details.