11 ms·

The Plan for React 18

144 points by joeyespo 5y ago

steve_adams_86 5y ago
I'm excited about concurrent mode. We're using it in production to help make a search function 'feel' faster, and it's very effective. Of course our focus is still making things actually faster, but concurrent mode goes a long way way in improving user experience which is essential. One thing I need to wrap my head around is avoiding unnecessary work with useDeferredValue, for example. I've got something set up which will defer multiple values, but I know the user will only want the most recent value by the time something can render. As a result, once values arrive it'll kind of cycle through each rendered value rapidly before stopping at the last one. I guess I need to implement some sort of throttling and/or debouncing under the hood better - this probably isn't up to concurrent mode to solve for me. I'm glad to see batching being focused on. I have code which implements batching to some degree, and it's always struck me as so awkward that I can't rely on React to make good decisions for me in this area. The abstraction required in a context provider or component to accomplish this is fairly ugly and really gets in the way of focusing on the component's core responsibility. I think this will be a great improvement.
- danabramov 5y ago
  >I'm excited about concurrent mode. Tiny nitpick--we'd like to stop referring to it as a "mode" since the new gradual strategy is opt-in per feature. :-) >As a result, once values arrive it'll kind of cycle through each rendered value rapidly before stopping at the last one. Have you tried the latest alpha? The behavior you're describing sounds like a bug we fixed a few months ago. See https://github.com/facebook/react/issues/17185#issuecomment-805291391 https://github.com/facebook/react/issues/17185#issuecomment-....
  - steve_adams_86 5y ago
    That's exactly it! Thank you! > Tiny nitpick Haha, 10-4 - I'll drop the habit
cglong 5y ago
I've been out of React for a little while now; what's the tl;dr for concurrent rendering and why was there concern about it breaking existing apps?
- CGamesPlay 5y ago
  I think the gist of it is that JavaScript doesn't have threads, or isolated state. So your code can theoretically do anything it wants, but the React concurrency stuff is riding on your code only using a specific set of APIs, and does things like calling your functions on cloned instances with different props. If you aren't writing your code "in the React way" it very quickly leads to very confusing inconsistent behaviors.
- danabramov 5y ago
  Not exactly a tl;dr but some examples of features unlocked by it: - https://github.com/reactwg/react-18/discussions/41 https://github.com/reactwg/react-18/discussions/41 - https://github.com/reactwg/react-18/discussions/37 https://github.com/reactwg/react-18/discussions/37 Maybe somebody else has the energy to summarize them. :-) The concern was because the old approach was to change the behavior globally. The new approach is to make it opt-in when you use specific new features that rely on it.
- wccrawford 5y ago
  At a guess, I'd say "Side effects in render functions". People might be doing things in render that aren't generally considered safe or wise, and forcing concurrent rendering on them would run that code multiple times immediately, instead of the expected "once per render". The new version apparently doesn't do that, unless you specifically use one of the new features, which means that you have accepted the other caveats for that scenario.
kbuchanan 5y ago
I just wanna give a shoutout to Facebook for finding a balance between rapid, innovative development on a major library without constantly introducing breaking changes. On the backend I'm a Clojure dev, and this approach has long been a standard in clojure.core which has earned my loyalty for many years. Wish more projects could be like this.
- Stevvo 5y ago
  Whilst the major changes are not technically breaking, they are culturally breaking; e.g. ask for help how to do something with classes, and you are likely to get someone telling you to "just use hooks instead". I've never encountered another library whose users are such opinionated assholes.
  - acdlite 5y ago
    Who are these jerk users? I'm going to give them a noogie! In all seriousness, I'm sorry you had such a bad experience. That's not what we want the React community to be. Next time, feel free to tag me or someone else on the core team and we'll tell them to cut it out.
  - deleted 5y ago
    [deleted]
_the_inflator 5y ago
Interesting approach: Working Group as a model to allow community participation.
travisd 5y ago
Does this include suspense for data fetching? Edit: seems so! Post links to a release announcement on GitHub which says it’s “fully” supported.
- danabramov 5y ago
  I'd say we can say Suspense for data fetching is "done" when Server Components (https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react...) and built-in Suspense Cache (https://github.com/reactwg/react-18/discussions/25 https://github.com/reactwg/react-18/discussions/25) are finalized. I would expect this to happen at some point during the 18.x release timeline, but maybe not in the initial release. However, React 18 does include a ton of work around Suspense, including: - Fixes to quirks in its existing behavior (https://github.com/reactwg/react-18/discussions/7 https://github.com/reactwg/react-18/discussions/7) - startTransition API which lets you implement the "show old content while new data is loading" UX (https://github.com/reactwg/react-18/discussions/41 https://github.com/reactwg/react-18/discussions/41) - A whole new server renderer that uses <Suspense> for streaming HTML and hydrating the page in independent parts (https://github.com/reactwg/react-18/discussions/37 https://github.com/reactwg/react-18/discussions/37) So it's ongoing but maybe the "whole story" including recommended patterns will not quite be in the initial scope in 18.0 release. I edited the announcement to clarify this.
flowerlad 5y ago
Automatic batching appears to cause problems, because the screen doesn't update when it needs to. Here's the scenario: User is holding down the down arrow key. On each key event you have to update the screen so that appears to scroll up. But React gets in the way by batching setStates, and this causes the screen updates to be jumpy. Now you have to find a workaround. This is an example of React doing too much.
- danabramov 5y ago
  >On each key event you have to update the screen so that appears to scroll up. But React gets in the way by batching setStates This does not sound correct. Quoting directly from the page on automated batching (https://github.com/reactwg/react-18/discussions/21 https://github.com/reactwg/react-18/discussions/21): >Note: React only batches updates when it’s generally safe to do. For example, React ensures that for each user-initiated event like a click or a keypress, the DOM is fully updated before the next event. This ensures, for example, that a form that disables on submit can’t be submitted twice. If you see a problem like the one you're describing, please file an issue in the main React repo, and we'll have a look. I'm not sure how you could have experienced this behavior since we released the alpha an hour ago.
  - flowerlad 5y ago
    To clarify, I am not talking about the React 18 feature. I have this problem in React 17. On Pagedown key, I throttle the setState calls because calling it too fast causes React to batch the updates. I'll try to make an standalone repro and open an issue in the React repo.
    - danabramov 5y ago
      Automatic batching is new in 18 so I suspect something else is up. A repro case would be highly appreciated! Thanks.
- acdlite 5y ago
  We have a mechanism to handle this exact scenario. We classify certain user input events, like keypresses and clicks, as "discrete" events. Updates that are triggered from discrete event will always be processed sequentially. We don't batch multiple events. Although we do batch multiple setStates within the same event, which is different. "Automatic batching" refers to the updates themselves, not the events. We call non-discrete events (like mousemove) "continuous", and for those we will batch updates across multiple events. We've been testing this at Facebook for a while and we think our model is really solid, handling all the common cases and a bunch of edge cases, too. If you try it out and find something unexpected, please let us know and we'll fix it!
no_wizard 5y ago
I hope the modules get re-organized to be tree-shakable. Native es module exports would also be nice! Smaller bundle sizes are always a plus
- acdlite 5y ago
  We do intend to ship a ES module build of React in the near future. Because that's a breaking change that could require significant changes to existing apps (i.e. to update the imports), we'll likely wait until the next major release cycle. However, note that tree-shaking probably won't help much in the case of React. React isn't a library of independently useful features; it's a cohesive framework where features work together. We also have a really small API surface area. So there's no much to "shake" apart. Arguably the main `react` package would benefit slightly from tree shaking, but those exports are already really small. The `react` package doesn't contain that much implementation; it mostly just calls into internal React DOM to schedule updates.
  - no_wizard 5y ago
    you can ship both commonjs and es modules using export maps, so it doesn't have to be a breaking change. You can use export conditions. anyone who cares enough will opt in to use es modules, of this I'm certain. Is there a reason that is not being considered?
- acemarke 5y ago
  Agreed that having React available as native ES Modules would be good. There's an open issue on that: https://github.com/facebook/react/issues/11503 https://github.com/facebook/react/issues/11503 However, there really isn't anything to tree-shake in React. The renderer implementation is effectively a single consolidated set of logic that handles all work for all types of components. So, there's no unused functions to get shaken out.
tekstar 5y ago
I use React (well, Preact) every day. I use it 2014-style. Class-based components, componentWillMount, render, callbacks, and that's about it. I love this workflow, and generally structure all my UIs this way regardless of platform - have a state struct and then fully render the UI as a function of the state. To me, that's the big hurrah for using React. But I have no clue why React is at version 18 and why it keeps getting new features. I'm perfectly happy making quite complicated UIs with the pattern I know well. Should I be following along? Does it matter?
- no_wizard 5y ago
  In this way react is choose your own adventure. There is no current signal that the way class components work will change and I don’t exactly expect that to happen any time soon if at all. Rather then new features are aimed at developers with more complex use cases and make heavy use of asynchronous data fetching in a way that lends itself to concurrency. If this isn’t you I’m sure at least the general performance improvements will be nice otherwise I don’t see why you can’t just keep doing what you’re doing
- dstaley 5y ago
  As someone who was initially resistant to hooks, I actually find that they're a more expressive API to how I was already thinking about my applications. There's footguns for sure, just like there are with class components, but I found that rewriting my class components with hooks instead actually made the code cleaner and easier to reason about. That being said, it's possible the benefit simply came from the rewrite, but even with newer components, I feel like hooks are a better API.
- srpoder 5y ago
  React hooks might be the best feature ever, once you understand it, it provides you a way to write highly reusable code.
- enlyth 5y ago
  I personally fell in love with hooks after initially disliking them, you should give it a try, maybe in a toy personal project, to see if you like it. It is great for separation of concerns. You basically stick to writing pure functional components focused only on how to render, and try to abstract reusable logic into hooks, and expose only what you need For example, you could make a useApi() hook and inside your component just do const { data, loading, error } = useApi('/endpoint'), so you can hide everything you don't need away from the rendering logic
gervwyk 5y ago
Really looking forward to new server side components and suspense. Also, kudos the the React / facebook team for building such an exceptional framework. React has really enabled small teams like ours to build large applications and even a framework! It takes a lot of dedication and careful planning to create such a versatile lib for a broad audience. 8 years down the road and the team is still keeping it together while innovating web-dev to new frontiers. Thanks again! And keep up the good work.
- e12e 5y ago
  Interesting, I never did notice this bit in my previous readings of this interview: > I had also put the foundation in place, to ensure that React components could be server rendered - and that feature was more so inspired by demand and constraints at the time than any specific technology. "Jordan Walke Transcript from Thursday January 26th, 2017 Facebook Engineer | Creator of React.js & Reason" https://www.reactiflux.com/transcripts/jordan-walke https://www.reactiflux.com/transcripts/jordan-walke
mdoms 5y ago
Two things about React will never stop being funny to me, 1. An entire generation of front end developers have staked their careers on a framework developed by Facebook. Facebook! 2. The hooks API. I honestly thought this was a joke when I first saw it. Developers will talk about the elegance of functional components then go and use the hooks API.
- beckingz 5y ago
  What's funny about hooks?
  - recursive 5y ago
    I know this is controversial, but I find them hard to understand. When I call `useState()`, what's the identity of the state that I'm using? What ties the state together between subsequent invocations of my component? For example, I know that strange things happen if you conditionally invoke `useState()`. People like to talk about "functional components", but hooks seem to live and breathe on mysterious side effects that I don't understand.
    - jahewson 5y ago
      If only there was some way to discover how things worked... Some website where you could type “how react hooks work” and get dozens of articles and blog posts explaining it.
      - canadianfella 5y ago
        > If only there was That’s an annoying way to communicate.
      - mdoms 5y ago
        I understand how they work. That doesn't make the API any less insane.
      - recursive 5y ago
jaredcwhite 5y ago
I'd love to see web components support greatly enhanced in React 18. It's literally the only major JS library used on the frontend which still offers poor WC support.
tmitchel2 5y ago
Does anyone know if the alpha builds will work with react native? I'm really hoping so because the flickering between transitions when using latest relay is super annoying to get around.

144 points by joeyespo 5y ago

I'm excited about concurrent mode. We're using it in production to help make a search function 'feel' faster, and it's very effective. Of course our focus is still making things actually faster, but concurrent mode goes a long way way in improving user experience which is essential. One thing I need to wrap my head around is avoiding unnecessary work with useDeferredValue, for example. I've got something set up which will defer multiple values, but I know the user will only want the most recent value by the time something can render. As a result, once values arrive it'll kind of cycle through each rendered value rapidly before stopping at the last one. I guess I need to implement some sort of throttling and/or debouncing under the hood better - this probably isn't up to concurrent mode to solve for me. I'm glad to see batching being focused on. I have code which implements batching to some degree, and it's always struck me as so awkward that I can't rely on React to make good decisions for me in this area. The abstraction required in a context provider or component to accomplish this is fairly ugly and really gets in the way of focusing on the component's core responsibility. I think this will be a great improvement.

danabramov 5y ago
>I'm excited about concurrent mode. Tiny nitpick--we'd like to stop referring to it as a "mode" since the new gradual strategy is opt-in per feature. :-) >As a result, once values arrive it'll kind of cycle through each rendered value rapidly before stopping at the last one. Have you tried the latest alpha? The behavior you're describing sounds like a bug we fixed a few months ago. See https://github.com/facebook/react/issues/17185#issuecomment-805291391 https://github.com/facebook/react/issues/17185#issuecomment-....
- steve_adams_86 5y ago
  That's exactly it! Thank you! > Tiny nitpick Haha, 10-4 - I'll drop the habit

cglong 5y ago

I've been out of React for a little while now; what's the tl;dr for concurrent rendering and why was there concern about it breaking existing apps?

CGamesPlay 5y ago
I think the gist of it is that JavaScript doesn't have threads, or isolated state. So your code can theoretically do anything it wants, but the React concurrency stuff is riding on your code only using a specific set of APIs, and does things like calling your functions on cloned instances with different props. If you aren't writing your code "in the React way" it very quickly leads to very confusing inconsistent behaviors.
danabramov 5y ago
Not exactly a tl;dr but some examples of features unlocked by it: - https://github.com/reactwg/react-18/discussions/41 https://github.com/reactwg/react-18/discussions/41 - https://github.com/reactwg/react-18/discussions/37 https://github.com/reactwg/react-18/discussions/37 Maybe somebody else has the energy to summarize them. :-) The concern was because the old approach was to change the behavior globally. The new approach is to make it opt-in when you use specific new features that rely on it.
wccrawford 5y ago
At a guess, I'd say "Side effects in render functions". People might be doing things in render that aren't generally considered safe or wise, and forcing concurrent rendering on them would run that code multiple times immediately, instead of the expected "once per render". The new version apparently doesn't do that, unless you specifically use one of the new features, which means that you have accepted the other caveats for that scenario.

kbuchanan 5y ago

I just wanna give a shoutout to Facebook for finding a balance between rapid, innovative development on a major library without constantly introducing breaking changes. On the backend I'm a Clojure dev, and this approach has long been a standard in clojure.core which has earned my loyalty for many years. Wish more projects could be like this.

Stevvo 5y ago
Whilst the major changes are not technically breaking, they are culturally breaking; e.g. ask for help how to do something with classes, and you are likely to get someone telling you to "just use hooks instead". I've never encountered another library whose users are such opinionated assholes.
- acdlite 5y ago
  Who are these jerk users? I'm going to give them a noogie! In all seriousness, I'm sorry you had such a bad experience. That's not what we want the React community to be. Next time, feel free to tag me or someone else on the core team and we'll tell them to cut it out.
- deleted 5y ago
  [deleted]

_the_inflator 5y ago

Interesting approach: Working Group as a model to allow community participation.

travisd 5y ago

Does this include suspense for data fetching? Edit: seems so! Post links to a release announcement on GitHub which says it’s “fully” supported.

danabramov 5y ago
I'd say we can say Suspense for data fetching is "done" when Server Components (https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react...) and built-in Suspense Cache (https://github.com/reactwg/react-18/discussions/25 https://github.com/reactwg/react-18/discussions/25) are finalized. I would expect this to happen at some point during the 18.x release timeline, but maybe not in the initial release. However, React 18 does include a ton of work around Suspense, including: - Fixes to quirks in its existing behavior (https://github.com/reactwg/react-18/discussions/7 https://github.com/reactwg/react-18/discussions/7) - startTransition API which lets you implement the "show old content while new data is loading" UX (https://github.com/reactwg/react-18/discussions/41 https://github.com/reactwg/react-18/discussions/41) - A whole new server renderer that uses <Suspense> for streaming HTML and hydrating the page in independent parts (https://github.com/reactwg/react-18/discussions/37 https://github.com/reactwg/react-18/discussions/37) So it's ongoing but maybe the "whole story" including recommended patterns will not quite be in the initial scope in 18.0 release. I edited the announcement to clarify this.

flowerlad 5y ago

Automatic batching appears to cause problems, because the screen doesn't update when it needs to. Here's the scenario: User is holding down the down arrow key. On each key event you have to update the screen so that appears to scroll up. But React gets in the way by batching setStates, and this causes the screen updates to be jumpy. Now you have to find a workaround. This is an example of React doing too much.

danabramov 5y ago
>On each key event you have to update the screen so that appears to scroll up. But React gets in the way by batching setStates This does not sound correct. Quoting directly from the page on automated batching (https://github.com/reactwg/react-18/discussions/21 https://github.com/reactwg/react-18/discussions/21): >Note: React only batches updates when it’s generally safe to do. For example, React ensures that for each user-initiated event like a click or a keypress, the DOM is fully updated before the next event. This ensures, for example, that a form that disables on submit can’t be submitted twice. If you see a problem like the one you're describing, please file an issue in the main React repo, and we'll have a look. I'm not sure how you could have experienced this behavior since we released the alpha an hour ago.
- flowerlad 5y ago
  To clarify, I am not talking about the React 18 feature. I have this problem in React 17. On Pagedown key, I throttle the setState calls because calling it too fast causes React to batch the updates. I'll try to make an standalone repro and open an issue in the React repo.
  - danabramov 5y ago
    Automatic batching is new in 18 so I suspect something else is up. A repro case would be highly appreciated! Thanks.
acdlite 5y ago
We have a mechanism to handle this exact scenario. We classify certain user input events, like keypresses and clicks, as "discrete" events. Updates that are triggered from discrete event will always be processed sequentially. We don't batch multiple events. Although we do batch multiple setStates within the same event, which is different. "Automatic batching" refers to the updates themselves, not the events. We call non-discrete events (like mousemove) "continuous", and for those we will batch updates across multiple events. We've been testing this at Facebook for a while and we think our model is really solid, handling all the common cases and a bunch of edge cases, too. If you try it out and find something unexpected, please let us know and we'll fix it!

no_wizard 5y ago

I hope the modules get re-organized to be tree-shakable. Native es module exports would also be nice! Smaller bundle sizes are always a plus

acdlite 5y ago
We do intend to ship a ES module build of React in the near future. Because that's a breaking change that could require significant changes to existing apps (i.e. to update the imports), we'll likely wait until the next major release cycle. However, note that tree-shaking probably won't help much in the case of React. React isn't a library of independently useful features; it's a cohesive framework where features work together. We also have a really small API surface area. So there's no much to "shake" apart. Arguably the main `react` package would benefit slightly from tree shaking, but those exports are already really small. The `react` package doesn't contain that much implementation; it mostly just calls into internal React DOM to schedule updates.
- no_wizard 5y ago
  you can ship both commonjs and es modules using export maps, so it doesn't have to be a breaking change. You can use export conditions. anyone who cares enough will opt in to use es modules, of this I'm certain. Is there a reason that is not being considered?
acemarke 5y ago
Agreed that having React available as native ES Modules would be good. There's an open issue on that: https://github.com/facebook/react/issues/11503 https://github.com/facebook/react/issues/11503 However, there really isn't anything to tree-shake in React. The renderer implementation is effectively a single consolidated set of logic that handles all work for all types of components. So, there's no unused functions to get shaken out.

tekstar 5y ago

I use React (well, Preact) every day. I use it 2014-style. Class-based components, componentWillMount, render, callbacks, and that's about it. I love this workflow, and generally structure all my UIs this way regardless of platform - have a state struct and then fully render the UI as a function of the state. To me, that's the big hurrah for using React. But I have no clue why React is at version 18 and why it keeps getting new features. I'm perfectly happy making quite complicated UIs with the pattern I know well. Should I be following along? Does it matter?

no_wizard 5y ago
In this way react is choose your own adventure. There is no current signal that the way class components work will change and I don’t exactly expect that to happen any time soon if at all. Rather then new features are aimed at developers with more complex use cases and make heavy use of asynchronous data fetching in a way that lends itself to concurrency. If this isn’t you I’m sure at least the general performance improvements will be nice otherwise I don’t see why you can’t just keep doing what you’re doing
dstaley 5y ago
As someone who was initially resistant to hooks, I actually find that they're a more expressive API to how I was already thinking about my applications. There's footguns for sure, just like there are with class components, but I found that rewriting my class components with hooks instead actually made the code cleaner and easier to reason about. That being said, it's possible the benefit simply came from the rewrite, but even with newer components, I feel like hooks are a better API.
srpoder 5y ago
React hooks might be the best feature ever, once you understand it, it provides you a way to write highly reusable code.
enlyth 5y ago
I personally fell in love with hooks after initially disliking them, you should give it a try, maybe in a toy personal project, to see if you like it. It is great for separation of concerns. You basically stick to writing pure functional components focused only on how to render, and try to abstract reusable logic into hooks, and expose only what you need For example, you could make a useApi() hook and inside your component just do const { data, loading, error } = useApi('/endpoint'), so you can hide everything you don't need away from the rendering logic

gervwyk 5y ago

Really looking forward to new server side components and suspense. Also, kudos the the React / facebook team for building such an exceptional framework. React has really enabled small teams like ours to build large applications and even a framework! It takes a lot of dedication and careful planning to create such a versatile lib for a broad audience. 8 years down the road and the team is still keeping it together while innovating web-dev to new frontiers. Thanks again! And keep up the good work.

e12e 5y ago
Interesting, I never did notice this bit in my previous readings of this interview: > I had also put the foundation in place, to ensure that React components could be server rendered - and that feature was more so inspired by demand and constraints at the time than any specific technology. "Jordan Walke Transcript from Thursday January 26th, 2017 Facebook Engineer | Creator of React.js & Reason" https://www.reactiflux.com/transcripts/jordan-walke https://www.reactiflux.com/transcripts/jordan-walke

mdoms 5y ago

Two things about React will never stop being funny to me, 1. An entire generation of front end developers have staked their careers on a framework developed by Facebook. Facebook! 2. The hooks API. I honestly thought this was a joke when I first saw it. Developers will talk about the elegance of functional components then go and use the hooks API.

beckingz 5y ago
What's funny about hooks?
- recursive 5y ago
  I know this is controversial, but I find them hard to understand. When I call `useState()`, what's the identity of the state that I'm using? What ties the state together between subsequent invocations of my component? For example, I know that strange things happen if you conditionally invoke `useState()`. People like to talk about "functional components", but hooks seem to live and breathe on mysterious side effects that I don't understand.
  - jahewson 5y ago
    If only there was some way to discover how things worked... Some website where you could type “how react hooks work” and get dozens of articles and blog posts explaining it.
    - canadianfella 5y ago
      > If only there was That’s an annoying way to communicate.
    - mdoms 5y ago
      I understand how they work. That doesn't make the API any less insane.
    - recursive 5y ago

jaredcwhite 5y ago

I'd love to see web components support greatly enhanced in React 18. It's literally the only major JS library used on the frontend which still offers poor WC support.

tmitchel2 5y ago

Does anyone know if the alpha builds will work with react native? I'm really hoping so because the flickering between transitions when using latest relay is super annoying to get around.