17 ms·

A Visual Guide to React Rendering

189 points by bpierre 5y ago

acemarke 5y ago
The author of this series has done an excellent job breaking down some of key aspects of React's rendering into good explanations with some nifty illustrations. As linked in this article, folks might also be interested in my very extensive post "A (Mostly) Complete Guide to React Rendering Behavior" [0], which goes into a lot more detail on the nuances of this. I also generally recommend reading some of Dan Abramov's posts that explain how and why React works, including the "Complete Guide to `useEffect`" [1], "React as a UI Runtime" [2], and "Before You memo()" [3]. Finally, it's worth noting that some of React's batching behavior will change in React 18 to always batch renders even across event loop ticks - see the React 18 Working Group post on "Automatic Batching for Fewer Renders" [4] for details. FWIW, some of this material is being incorporated into the upcoming React docs rewrite [5], which I'm really excited to see go live. [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-... [1] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/ [2] https://overreacted.io/react-as-a-ui-runtime/ https://overreacted.io/react-as-a-ui-runtime/ [3] https://overreacted.io/before-you-memo/ https://overreacted.io/before-you-memo/ [4] https://github.com/reactwg/react-18/discussions/21 https://github.com/reactwg/react-18/discussions/21 [5] https://github.com/reactjs/reactjs.org/issues/3308 https://github.com/reactjs/reactjs.org/issues/3308
- antman 5y ago
  You seem very knowlegable witb React abd really I cant wrap my head around it. Di you know any a short tutorial that would show best practices and shows the strengths of React?
  - noman-land 5y ago
    Not OP but Thinking In React[0] is a really good intro text. The docs in general are great and have gotten better over time. [0] https://reactjs.org/docs/thinking-in-react.html https://reactjs.org/docs/thinking-in-react.html
Aeolun 5y ago
This is great, but he could have gotten all of this memoization for free if he hadn’t switched from class based to function based components. Still, very helpful to introduce people to all the important concepts for hook based React.
- ioseph 5y ago
  How so? My understanding is you'd still need to implement shouldComponentUpdate in the class component.
  - dandelany 5y ago
    You can just use PureComponent instead of implementing shouldComponentUpdate, but you're right that it doesn't come "for free". PureComponent : class components :: memo : function components
LAC-Tech 5y ago
I have to say stuff like this is why I'm not a big fan of the component approach to frontend dev. Reasoning about when and why something gets updated is not very intuitive. The other thing that tends to happen is that components become god objects. People stuff all their business logic in there, and suddenly most files in the project have a tsx or jsx extension. It's winforms code behind all over again. "React is a library not a framework" starts sounding pretty hollow. It's possible to not do this, so I can't strictly blame react for this - but it's happened in every react project I've seen.
- ricardobeat 5y ago
  That’s more a consequence of hooks & context in React specifically , rather than the component model. There are other frameworks where it’s much easier to reason about updates.
  - LAC-Tech 5y ago
    What I meant by 'component' was the idea of state + templates being in the same thing. I prefer dumb views, but no issue with those dumb views being split up into sub views. But not 100% sure what you mean - could you expand?
    - ricardobeat 5y ago
      React encourages you to push state down, into components low in the tree, as seen in this article, which leads to "state and templates being in the same thing". But that is not a property of the component model; you can keep most of your components pure if you'd like, and keep the state and logic at a higher level. At that point there is little distinction between components and "sub views" in a template system. It would just be quite painful to work with. I do agree with your other point - it's almost impossible to use React as 'just a view library', it ends up permeating everything. I believe the hooks API aggravates both of these problems: the former by making it easier than the alternative patterns, the latter by creating function 'colors' that are contagious.
- coding123 5y ago
sktrdie 5y ago
Cool but I would like to understand the opposite: why doesn't React then just memoize everything by default? Why not let the developer opt-out of memoizing instead of having them opt-in?
- have_faith 5y ago
  Memoization isn't a free lunch. I think React's approach is to keep it simple with not managing cache stores for absolutely everything. Most small to medium react apps need little to no use of useMemo to be performant.
  - remram 5y ago
    If I remember correctly, React's default approach of comparing states/props is a shallow comparison (e.g. for PureComponent). That seems about as close to free as you can get. I use PureComponent everywhere, but I don't know what people do in function-component world.
cesarvarela 5y ago
Won't the diffing algorithm prevent a DOM update anyway?
- iaml 5y ago
  It will, but memo will prevent the actual function from being called as well.
  - wruza 5y ago
    If the framework is based on pure functions and no external state, what is the point of calling the entire subtree again and again?
    - iaml 5y ago
      It's not calling entire tree, when you do any hook/state changes only that component and everything down is called. Also, it's still not doing any dom changes, although I'm not sure what kind of performance impact it has nowadays. As to why, I don't really know, but as a dev using react I sure enjoy that I don't have to worry about some component losing track of state.
tored 5y ago
Great article but at the same time the absolute horror of what "modern" frontend development is. I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app, but I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend.
- MHard 5y ago
  From personal experience I can tell you that using a modern framework can be really worth the added complexity even in simple applications. For one of my clients projects it started out in what seemed like a simple crud app and so I did the few reactive changes in pure java script. The thing is: requirements changed and now after a while I couldn't get around adding VueJS simply because the reactive changes kept piling up. Even though the HN sentiment seems to be that all "modern" frameworks are just huge piles of code that you add to your project without understanding how any of this works, my personal opinion is that using something like nextjs with server side rendering is not all that different from using a server side php framework like laravel. You still generate the same html unless you need reactive changes and when you do, you are happy to have chosen that. And to play a bit the devil's advocate: Unless you write your own webserver and template rendering engine you are already using a bunch of code you don't really understand.
  - lunfard000 5y ago
    It is like questioning about backend using a spring boot in every single service even when it is only for a simple store and fetch json from mongoDB. If you have the know-how, why not? Jumping between Vanilla and React projects can be counterproductive. If things get more complex you are prepared, if not, nobody will mind.
  - tored 5y ago
    Reactive changes with server side templates is less complicated than using a frontend framework. Just fetch the pre-rendered HTML fragment and put into the page. Done. And the good thing is that you can render a server side component either as part of a full page load or separately for a dynamic update. But if you have decided to do frontend rendered templates, then I agree, pick one of the popular frameworks from the start of the project. Vue is IMHO a better pick than React, Vue has better ergonomics and is just better how everything is tied together. Vue is a well designed framework.
rk06 5y ago
Hold it, if react has such rendering issues, why any tech company or startup would use it, instead of angular/Vue? I can't think of any good reason beside react native. Is react native, so good that it can compensate for such serious flaws?
de_keyboard 5y ago
Great example of how the lack of custom value types really hurts JavaScript as a functional programming language. > [ 1, 2, 3 ] === [ 1, 2, 3 ] false Ridiculous!
- bpierre 5y ago
  Tuples are coming to JS: https://github.com/tc39/proposal-record-tuple#tuple https://github.com/tc39/proposal-record-tuple#tuple
  - de_keyboard 5y ago
    This would be such a huge improvement (and records too)!
- ThePadawan 5y ago
  I still get bitten by > [] == [] < false sometimes. And that's with two equal signs, not three!
  - phist_mcgee 5y ago
    Two separate references to two separate arrays equaling false? What's the problem?
    - ThePadawan 5y ago
      JS has a very "unique" opinion that that is how that should be interpreted. Given the same input as above: Python says True. Ruby says true. JS says false. And otherwise, JS is quite lenient with not interpreting the input like you describe it when using "==": > [] == 0 < true > [] == false < true
    - de_keyboard 5y ago
      When doing functional programming, immutable lists with value comparison are what you want. However with JS, you only get mutable arrays with reference equality out-of-the-box. You can use a library, as others have point out, but then your code gets very noisy.

189 points by bpierre 5y ago

The author of this series has done an excellent job breaking down some of key aspects of React's rendering into good explanations with some nifty illustrations. As linked in this article, folks might also be interested in my very extensive post "A (Mostly) Complete Guide to React Rendering Behavior" [0], which goes into a lot more detail on the nuances of this. I also generally recommend reading some of Dan Abramov's posts that explain how and why React works, including the "Complete Guide to `useEffect`" [1], "React as a UI Runtime" [2], and "Before You memo()" [3]. Finally, it's worth noting that some of React's batching behavior will change in React 18 to always batch renders even across event loop ticks - see the React 18 Working Group post on "Automatic Batching for Fewer Renders" [4] for details. FWIW, some of this material is being incorporated into the upcoming React docs rewrite [5], which I'm really excited to see go live. [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-... [1] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/ [2] https://overreacted.io/react-as-a-ui-runtime/ https://overreacted.io/react-as-a-ui-runtime/ [3] https://overreacted.io/before-you-memo/ https://overreacted.io/before-you-memo/ [4] https://github.com/reactwg/react-18/discussions/21 https://github.com/reactwg/react-18/discussions/21 [5] https://github.com/reactjs/reactjs.org/issues/3308 https://github.com/reactjs/reactjs.org/issues/3308

antman 5y ago
You seem very knowlegable witb React abd really I cant wrap my head around it. Di you know any a short tutorial that would show best practices and shows the strengths of React?
- noman-land 5y ago
  Not OP but Thinking In React[0] is a really good intro text. The docs in general are great and have gotten better over time. [0] https://reactjs.org/docs/thinking-in-react.html https://reactjs.org/docs/thinking-in-react.html

Aeolun 5y ago

This is great, but he could have gotten all of this memoization for free if he hadn’t switched from class based to function based components. Still, very helpful to introduce people to all the important concepts for hook based React.

ioseph 5y ago
How so? My understanding is you'd still need to implement shouldComponentUpdate in the class component.
- dandelany 5y ago
  You can just use PureComponent instead of implementing shouldComponentUpdate, but you're right that it doesn't come "for free". PureComponent : class components :: memo : function components

LAC-Tech 5y ago

I have to say stuff like this is why I'm not a big fan of the component approach to frontend dev. Reasoning about when and why something gets updated is not very intuitive. The other thing that tends to happen is that components become god objects. People stuff all their business logic in there, and suddenly most files in the project have a tsx or jsx extension. It's winforms code behind all over again. "React is a library not a framework" starts sounding pretty hollow. It's possible to not do this, so I can't strictly blame react for this - but it's happened in every react project I've seen.

ricardobeat 5y ago
That’s more a consequence of hooks & context in React specifically , rather than the component model. There are other frameworks where it’s much easier to reason about updates.
- LAC-Tech 5y ago
  What I meant by 'component' was the idea of state + templates being in the same thing. I prefer dumb views, but no issue with those dumb views being split up into sub views. But not 100% sure what you mean - could you expand?
  - ricardobeat 5y ago
    React encourages you to push state down, into components low in the tree, as seen in this article, which leads to "state and templates being in the same thing". But that is not a property of the component model; you can keep most of your components pure if you'd like, and keep the state and logic at a higher level. At that point there is little distinction between components and "sub views" in a template system. It would just be quite painful to work with. I do agree with your other point - it's almost impossible to use React as 'just a view library', it ends up permeating everything. I believe the hooks API aggravates both of these problems: the former by making it easier than the alternative patterns, the latter by creating function 'colors' that are contagious.
coding123 5y ago

sktrdie 5y ago

Cool but I would like to understand the opposite: why doesn't React then just memoize everything by default? Why not let the developer opt-out of memoizing instead of having them opt-in?

have_faith 5y ago
Memoization isn't a free lunch. I think React's approach is to keep it simple with not managing cache stores for absolutely everything. Most small to medium react apps need little to no use of useMemo to be performant.
- remram 5y ago
  If I remember correctly, React's default approach of comparing states/props is a shallow comparison (e.g. for PureComponent). That seems about as close to free as you can get. I use PureComponent everywhere, but I don't know what people do in function-component world.

cesarvarela 5y ago

Won't the diffing algorithm prevent a DOM update anyway?

iaml 5y ago
It will, but memo will prevent the actual function from being called as well.
- wruza 5y ago
  If the framework is based on pure functions and no external state, what is the point of calling the entire subtree again and again?
  - iaml 5y ago
    It's not calling entire tree, when you do any hook/state changes only that component and everything down is called. Also, it's still not doing any dom changes, although I'm not sure what kind of performance impact it has nowadays. As to why, I don't really know, but as a dev using react I sure enjoy that I don't have to worry about some component losing track of state.

tored 5y ago

Great article but at the same time the absolute horror of what "modern" frontend development is. I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app, but I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend.

MHard 5y ago
From personal experience I can tell you that using a modern framework can be really worth the added complexity even in simple applications. For one of my clients projects it started out in what seemed like a simple crud app and so I did the few reactive changes in pure java script. The thing is: requirements changed and now after a while I couldn't get around adding VueJS simply because the reactive changes kept piling up. Even though the HN sentiment seems to be that all "modern" frameworks are just huge piles of code that you add to your project without understanding how any of this works, my personal opinion is that using something like nextjs with server side rendering is not all that different from using a server side php framework like laravel. You still generate the same html unless you need reactive changes and when you do, you are happy to have chosen that. And to play a bit the devil's advocate: Unless you write your own webserver and template rendering engine you are already using a bunch of code you don't really understand.
- lunfard000 5y ago
  It is like questioning about backend using a spring boot in every single service even when it is only for a simple store and fetch json from mongoDB. If you have the know-how, why not? Jumping between Vanilla and React projects can be counterproductive. If things get more complex you are prepared, if not, nobody will mind.
- tored 5y ago
  Reactive changes with server side templates is less complicated than using a frontend framework. Just fetch the pre-rendered HTML fragment and put into the page. Done. And the good thing is that you can render a server side component either as part of a full page load or separately for a dynamic update. But if you have decided to do frontend rendered templates, then I agree, pick one of the popular frameworks from the start of the project. Vue is IMHO a better pick than React, Vue has better ergonomics and is just better how everything is tied together. Vue is a well designed framework.

rk06 5y ago

Hold it, if react has such rendering issues, why any tech company or startup would use it, instead of angular/Vue? I can't think of any good reason beside react native. Is react native, so good that it can compensate for such serious flaws?

de_keyboard 5y ago

Great example of how the lack of custom value types really hurts JavaScript as a functional programming language. > [ 1, 2, 3 ] === [ 1, 2, 3 ] false Ridiculous!

bpierre 5y ago
Tuples are coming to JS: https://github.com/tc39/proposal-record-tuple#tuple https://github.com/tc39/proposal-record-tuple#tuple
- de_keyboard 5y ago
  This would be such a huge improvement (and records too)!
ThePadawan 5y ago
I still get bitten by > [] == [] < false sometimes. And that's with two equal signs, not three!
- phist_mcgee 5y ago
  Two separate references to two separate arrays equaling false? What's the problem?
  - ThePadawan 5y ago
    JS has a very "unique" opinion that that is how that should be interpreted. Given the same input as above: Python says True. Ruby says true. JS says false. And otherwise, JS is quite lenient with not interpreting the input like you describe it when using "==": > [] == 0 < true > [] == false < true
  - de_keyboard 5y ago
    When doing functional programming, immutable lists with value comparison are what you want. However with JS, you only get mutable arrays with reference equality out-of-the-box. You can use a library, as others have point out, but then your code gets very noisy.