3 ms·

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.