8 ms·
A mostly complete guide to React rendering behavior (2020)
- acemarke 2y agoOh hey, that's my post! Note that I did a fairly extensive update to it in 2022 to cover React 18.
- dylanhu 2y agoAny plans to update again to include React Server Components?
- acemarke 2y agoNot at this time. I'm pretty full up at this point with day job ( https://replay.io https://replay.io ), conferences, and personal life stuff. My current ongoing Redux maintenance task is trying to revamp our "Redux Essentials" tutorial to be TS-first. Making slower progress on that than I'd wanted, but hopefully can get that wrapped up in the not _too_ distant future. Beyond that, we've got a ton of open RTK Query feature requests that I'd like to address later on this year.
- nsonha 2y agoanyone knows the status of the React Forget thingy?
- recursive 2y agoThe flagship feature of React 19 is a "compiler", but doesn't seem to have the main features of Forget. (inferred effect dependencies) I'm guessing it's not coming any time soon.
- acemarke 2y agoReact 19, a library release, is completely separate from the eventual release of the React Compiler build tool (which is currently implemented as a Babel plugin wrapper around a full compiler implementation core). That said, React Compiler will _depend_ on React 19, because it needs a new memo/caching hook that will be included in 19.
- mst 2y agoI wonder how it compares to https://github.com/ryansolid/dom-expressions/tree/main/packages/babel-plugin-jsx-dom-expressions#babel-plugin-jsx-dom-expressions https://github.com/ryansolid/dom-expressions/tree/main/packa...
- klysm 2y agoI feel like making it compiled is a mistake. It will split the world in two
- acemarke 2y agoIt's now called "React Compiler". It's not released yet, but the dev team has been saying it'll be out _after_ React 19 but "sooner than you think": - https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024#react-compiler https://react.dev/blog/2024/02/15/react-labs-what-we-have-be... - https://twitter.com/potetotes/status/1783713677943656819 https://twitter.com/potetotes/status/1783713677943656819
- mst 2y agoTangentially, Solid is fascinating - especially the dom-expressions backend meaning you can basically bolt compilation behaviour into anything that supports that. I have https://github.com/ryansolid/mobx-jsx/?tab=readme-ov-file#mobx-jsx https://github.com/ryansolid/mobx-jsx/?tab=readme-ov-file#mo... on my list to try since I -really- like mobx for stage management (especially mobx-keystone) and am fascinated by how clean the results can be. Though for 'real' code I still tend to default to react + mobx-keystone because for all my gripes with react it's a pretty solid Schelling Point.
- SPascareli13 2y agoNot a critic to the article itself, in fact I know nothing about React and learned a lot from the it, but...do we REALLY need all of this to render web pages? Even if it is a web application and not just a page, doesn't this ecosystem seem too complicated for the problem it solves?
- echelon 2y agoThese aren't just web pages. They're full applications with robust, rich state. Web apps can reach the complexity of a desktop app with a GUI, a game, etc. I say this as a mostly backend / systems engineer: there is an incredible wealth of complexity in the frontend. In user interaction, making and transforming API calls, and in UI/UX design.
- bobthepanda 2y agoso long as browsers don't have a great way to be stateful, and tie that state to markup, then there will be a couple of major frameworks trying to square that circle. the moment you have to keep track of any type of state, managing dozens of UI elements quickly becomes extremely tedious.
- klysm 2y agoNope we don’t, but it solves a lot of the problems people frequently encounter while building web pages without too much of a downside. It’s a big trade off space and react sits in a very nice spot in that space.
- vcarl 2y agoPhenomenal answer. No, you don't need it, but if you build something long enough you'll avoid a couple categories of common problems by starting with it (and choose a different set of common problems)
- klysm 2y agoI like to think about framework choices as choosing which kind of problems you are okay with experiencing. This choice can be made from a product perspective much easier
- gofreddygo 2y agoya'know, everytime there's a post with react in the title, I open it with the best positive attitude I can muster, holding back my knee jerk reaction. I then read it, and come out thinking "why, why, why do people put up with this absurdity?" and always stop at the same conclusion, cz they don't know any better. I then quietly move on with my life, sometimes leaving such comments as hints to those who might catch on.
- blackhaj7 2y agoWhat’s absurd about it? What’s a better option in your opinion? Asking as someone who mostly knows the React approach
- cynicalsecurity 2y agoJust generate a web page on the backend. Sprinkle it a bit with some simple JavaScript/jQuery code for animations, forms checking etc, if you want. That's it. That's how it was supposed to work and that's how it works best. JavaScript was made to make the monkey dance. The end result, either made with overcomplicates frameworks like React/Angular or with simply generating the web page on the backend, is irrelevant to the user.
- MajimasEyepatch 2y agoSo what should they be using, if they did know better?
- klysm 2y agoReally thorough! Best opening explanation of react render behavior I’ve read to date. One of my goto interview questions for front end devs is “when does react render?”
- weatherlite 2y agoThere are only three hard problems in computer science: Cache invalidation, naming things and React rendering behavior.
- phendrenad2 2y agoThis is already mostly out-of-date, right?
- matharmin 2y agoUpdated in 2022, but I don't see anything on <Suspense> for example. That doesn't necessarily mean the info is now wrong, but it's definitely not complete anymore.
- acemarke 2y agoI did title it "_Mostly_ Complete Guide" for a reason :) Everything in that post should still be 100% accurate and relevant. I specifically did _not_ try to go into further details on Suspense or some of the intricacies of Concurrent Rendering (beyond "React can cancel or reset those render passes"). My overall goal was to explain the core mental model of how React's basic rendering works on the client side. As far as Suspense goes, that can be summarized as "throw a promise while rendering, `<Suspense>` acts like a `try/catch` at the component level, React will re-render this component when the promise resolves and from its perspective that function call _always_ returned the data synchronously". Concurrent Rendering is really complicated internally, but loosely: React has an internal notion of priorities for queued renders. `startTransition`, `useDeferredValue`, and Suspense all mark renders as low priority, so those render passes can be "rebased", interrupted, or canceled as needed based on updates that come in later.