A Visual Guide to React Rendering

https://alexsidorenko.com/blog/react-render-always-rerenders/

by bpierre • 5 years ago

189 76 5 years ago

acemarke2• 5 years 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-...

[1] https://overreacted.io/a-complete-guide-to-useeffect/

[2] https://overreacted.io/react-as-a-ui-runtime/

[3] https://overreacted.io/before-you-memo/

[4] https://github.com/reactwg/react-18/discussions/21

[5] https://github.com/reactjs/reactjs.org/issues/3308

antman• 5 years 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• 5 years 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

Aeolun• 5 years 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• 5 years ago

How so? My understanding is you'd still need to implement shouldComponentUpdate in the class component.

dandelany• 5 years 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-Tech2• 5 years 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.

ricardobeat2• 5 years 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-Tech2• 5 years 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?

coding1232• 5 years ago

This is confusing because before component models, everything was a global.

I do agree about one thing though, before hooks, the standard recommendation was redux (or similar) I kept SCREAMING that it was a giant global anti-pattern. I don't think anyone understood that for the first 5 years of React. It seems like that whole thing is corrected now.

dvt2• 5 years ago

This is confusing because before component models, everything was a global.

Hot take: I'd argue this is confusing because (almost) everything should be a global in UI development. Plenty of websites were built in PHP and basic Javascript with (gasp) globals! I guess some folks don't understand that people have been making pretty complex web apps since before 2013. It's monumentally counterproductive having to deal with state management in like 40 nested components because you just want the username and user email to trickle down.

So people re-invented global state but we call it Redux now. It's a parody of a parody.

acemarke2• 5 years ago

Hooks don't really change anything about whether or not you use Redux, though. The only real difference is that there's now the `useReducer` hook, but that's just a different mechanism for updating the same component state we've always had architecturally.

FWIW, I maintain Redux, and I've written extensively trying to clarify when it does and doesn't make sense to use Redux, and how to use it the right way [0] [1] [2] [3] [4] [5]. No question there's been a lot of FUD and misconceptions about that over the years, and I wish I didn't have to spend so much time on this topic, but lots of people never look at our docs and actual recommendations.

Also worth noting that our Redux Toolkit package [6] and React-Redux hooks API [7] have made Redux _much_ easier to learn and use than it was previously, and we get a ton of very positive feedback about that.

[0] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

[1] https://changelog.com/posts/when-and-when-not-to-reach-for-r...

[2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[3] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

[4] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[5] https://redux.js.org/style-guide/style-guide

[6] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

[7] https://react-redux.js.org/api/hooks

FalconSensei• 5 years ago

the standard recommendation was redux (or similar)

Please don't remind me of that

arcosdev• 5 years ago

How is redux a giant global anti-pattern exactly? It does create a single source of truth, but I am not quite following. Can you explain this more?

wruza2• 5 years ago

before component models, everything was a global

Before react and vue everyone could create a mess, but it was not mandatory. Desktop frameworks always used sorts of controller hierarchy vs view hierarchy separation and didn’t store global data. There was decent ui before web/react (though it may sound crazy to react guys).

I don't think anyone understood that for the first 5 years of React

I bet that millions of developers who were not on the ~awesome hype train~ would look at this statement with a great confusion.

I’m not a react guy though, can someone explain where the data usually resides now? Right in a component state, I guess?

eyelidlessness• 5 years ago

You may want to look at SolidJS, and read some of the articles by its creator. The component model of dev doesn't imply any of this, even if the rendering approaches might learn from each other. Specifically: Solid has a component dev approach, but components vanish at runtime and it's just your reactive calls and the DOM from then on.

wonnage• 5 years ago

The alternative is manually hooking up a bunch of views that update by subscribing to some event bus, which quickly becomes unmanageable. I don't want to learn about all the custom events in the system to know how things update. And god help you if you have cascading/recursive events.

Your mental model for updates can be shared across all apps that use React and it's a huge blessing for getting up and running with an unfamiliar codebase.

Cthulhu_• 5 years ago

It's because while React offers a decent standard for declaring components, there is no standard for building an application with React as the rendering layer. I mean I've got an `api.ts` file somewhere with a TODO that says "I should probably split up API requests and business logic", but that's all handcrafted guesswork.

Angular, for all its flaws and the major mistake that was announcing Angular 2 to be a rewrite etc causing a big exodus, at least had an Opinion on how to build an application end to end.

thirdvect0r• 5 years ago

Yep, Angular 2+ is so much better than React and Vue precisely because it's so opinionated. In 4 years of using it I've only really had issues with serverside rendering and even that got resolved on the repo pretty quickly

hardwaresofton6• 5 years ago

Please:

- Try Vue[0], Lit[1] (it's a bit cutting edge but I really like it), or the other entries in the component-building library space

- Don't use redux/vuex all of that, and just write plain javascript objects that make fetch() calls

- Don't use hooks (yet)

If you do these things, you should find the component approach refreshing compared to copying and pasting HTML and managing event handlers/spaghetti and making your own structure. For all but the simplest of pages there should be an improvement over vanilla HTML+JS.

If it makes you feel better, if you squint React looks exactly like Backbone views, which had a reason for existing back when they did, and if you go even further back it's like COM[2].

[0] https://vuejs.org/

[1] https://lit.dev/

[2] https://www.bitquabit.com/post/the-more-things-change/

iaml4• 5 years ago

Don't use redux

This is a puzzling advice to give to someone who wants to offload business logic away from components, as redux with sagas for example is a great place to put it. That way if you use selectors (preferably memoized as well) your components will only update when needed and you can organize business logic however you want.

lunfard0002• 5 years ago

hooks are amazing, wtf

Abishek_Muthian2• 5 years ago

I just tried the pattern you recommended using Vue to build a simple Purchase Power Parity Calculator[1] as all current ones are outdated AFAIK.

I'm a least JS, 'You Might Not Need JQuery' kind of person so my complex web applications are all rendered in the back-end using Go but this particular website is static and this is the first time I've added some JS to it for a core function.

It does seem like Vue is a good fit for small front end reactive components like this, I'm refraining from passing further comments on the subject as this is the first time I've tried it.

[1] https://startuptoolchain.com/calculators/ppp.html

tenaciousDaniel• 5 years ago

Every project I've inherited has done this, and every time I go through the tedious process of separating UI logic from business logic. If done the right way, a component-oriented approach can be very nice.

But yes, if a dev thinks that React or Vue or whatever is somehow going to automatically create good architecture for them, then they're in for a bad time.

loftyal• 5 years ago

This is why you need to ask everyone who interviews "What is Container vs Presentational, and why is it good/bad". If you cannot give you a good answer don't hire them.

flowerlad2• 5 years ago

To solve this problem you can use React with an MVC framework. See https://github.com/wisercoder/mvc-router

sktrdie• 5 years 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• 5 years 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• 5 years 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• 5 years ago

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

iaml4• 5 years ago

It will, but memo will prevent the actual function from being called as well.

wruza2• 5 years 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?

tored4• 5 years 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• 5 years 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.

lunfard0002• 5 years 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.

tored4• 5 years 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.

midrus5• 5 years ago

It is not fair to compare SPA or big frontend frameworks with "pure JavaScript" or messy jQuery as some imply.

By putting 20% the effort we put nowadays with these big frameworks into well organized "sprinkles" it is a very viable alternatives. Tools such as Stimulus, unpoly, htmx,etc make this very approachable and maintainable.

To me, SPAs only make sense in two scenarios: 1) You have the requirement for the app to work offline, or on really bad network connections (subway, etc) or 2) You already have a team which only wants to do SPAs and everything else is uncool to them.

maeln• 5 years ago

I worked on multiple webapps that used react and, in a way yes, you could do server-side rendering. But the real advantage of react (and most other framework for that matter) is to be able to easily program pages that don't need to fully reload everytime you click on something. Sure, you can still do the same with SSR, but framework make it that much more simple and help a lot with separation of concern.

Also, it make task splitting between frontend and backend engineer that much more easier.

tored4• 5 years ago

It is definitely possible to do structured dynamic updates without page reloads with SSR because that is what we did 15 years ago before the JSON hype. I know because I worked with it then.

The need to separate the team into frontend & backend engineers is a direct consequence of the over complicated frontend frameworks.

That is another tragedy of this heavy frontend trend. We are undermining the team’s performance and makes it harder to finish deadlines.

Usually what happens is that the frontend & backend engineers get out of sync and starts working on other things until they can sync again.

When this happens too often there is push to put the backend and the frontend in different teams.

After the split the teams start evolving separate cultures and mindset how to solve things and soon enough both teams has their own build and deploy pipes.

Eventually the teams no longer feel that they share a mutual idea of common ownership and the project stagnates.

If we keep things nice & simple we can work as fullstack engineers together as a team.

flowerlad2• 5 years ago

React is indeed a complex library. For simple apps where components are simple and stateless React is easy. When you have more complex apps where components manage their own state and you have to also update the stateful component from outside, that's when the complexity starts. If the data rendered by the component is large and can't be easily cloned then it gets even more complicated.

solved with a simple template rendered in the backend

Or a simple template rendered in the frontend, see this demo, where no huge libs are used. Instead a 200-line lib is used to get the equivalent of stateless React components: https://github.com/wisercoder/eureka

azangru• 5 years ago

I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app

I am not sure about that. Look at Google. For their truly complex applications like a spreadsheet or word processor (Google docs) they seem to have given up on the DOM altogether and are reimplementing the whole UI in HTML5 canvas.

I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend

Yes, Google and the rest of the folks who are pushing for web components believe they can be.

midrus5• 5 years ago

THIS. Server side templates and something like Unpoly is what 90% of projects need.

But here I am at work, doing CRUD forms with rxjs, epics, redux, websockets and a shitton of home made packages for doing validation, lazy translations, mixing microfrontends, etc, etc.

tored4• 5 years ago

Unpoly looks really nice, something I need to investigate as a comparison against htmx.

Server Side Events (SSE) is better option to websockets IMHO, it is a much simpler protocol so you can implement in any backend of choice with a few lines because it just a HTTP request that is kept open for a longer period of time.

Websockets are bidirectional whereas SSE are unidirectional, but you rarely need the client to push huge data sets to the server.

And if you already have endpoints for fetching HTML fragments for rendering a components, SSE fits well as enhancement into that architecture to get a more live experience.

e.g.

model update in backend -> notify frontend with SSE that model changed -> component that renders model fetches new HTML fragment over HTTP.

This makes the messages over SSE tiny, only need to say that a model changed, not the entire model data. This means that you can turn off SSE and the applications still works, just without live updates thru push, e.g switch to timer based solution instead.

What is also nice by fetching HTML fragments over HTTP is that you use cache headers, if you already have the latest fragment that is just a 304 Not modified.

I think that SSR with dynamic updates of HTML fragments closer respects how the web was intended.

rk06• 5 years 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_keyboard3• 5 years 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• 5 years ago

Tuples are coming to JS: https://github.com/tc39/proposal-record-tuple#tuple

de_keyboard3• 5 years ago

This would be such a huge improvement (and records too)!

ThePadawan2• 5 years ago

I still get bitten by

[] == []

< false

sometimes. And that's with two equal signs, not three!

phist_mcgee• 5 years ago

Two separate references to two separate arrays equaling false? What's the problem?

addandsubtract• 5 years ago

underscore/lodash is pretty much the go-to extension to JS.

    > _.isEqual([ 1, 2, 3 ], [ 1, 2, 3 ])  
    true

A Visual Guide to React Rendering

Related Stories