"It has been two and a half years since the previous major release of React, which is a long time even by our standards!"<p>As a mostly Python and only occasional JavaScript developer, it always felt like the biggest challenge in the JavaScript community was how fast everything moved - new libraries, frameworks and ideas would tumble past at the rate of one every few weeks, and it felt impossible to keep up.<p>I've been feeling that a lot less recently, and maybe the fact that React has been steady for 2.5 years is part of the reason.
I'm excited to see the work on the Modern Event System land. I tried to dig into all the events code in React to understand how events in React Portals bubbled up because I wanted to prevent them from bubbling out of the portal in many cases (GH issue: <a href="https://github.com/facebook/react/issues/11387" rel="nofollow">https://github.com/facebook/react/issues/11387</a>). In 16.x, the modern event system was in the tree but unused by default, and it was very confusing to try to trace event handling logic between the two event systems. Removing the legacy event system will make the event system much more accessible to new contributors.<p>Can someone on the React team speak to how event delegation works when there are portals present? Where is the event handler for a portal bound, and how does the new events system handle event bubbling across multiple versions of React in portal trees?
I've become increasingly disillusioned with the JS ecosystem over the past couple of years, but React still delivers. I can still chuck it in a script tag and start writing components if needed (without JSX). I haven't really used hooks yet and don't plan to, but as long as "legacy" class based components are supported, I will use them.<p>Thanks for maintaining backward compatibility, which is not very common in the JS world. And congrats on the release!
I wish this approach to be followed by all major repos and maintainers and become a new trend across all the tech industry.<p>By creating `bridge` release, the React community created a safe, well know and stable release that works as bridge for the upcoming complex, feature rich, release.<p>So: Complex Release -> Stable `bridge` Release -> New Complex Release.<p>Anyone can stay as long as they want in the bridge release, others can quickly move forward to the next release cycle.
It contains a very serious breaking change: cleanup in useEffect is now being executed asynchronously. I might not be seeing something, but I think this means all patterns like the one below will now have hard to catch racing conditions.<p><pre><code> const [x, setX] = useState()
useEffect(() => {
let isMounted = true
someAsyncFunc(result => {
if (isMounted) {
setX(result) // should not be called on dismounted component
}
})
return () => { isMounted = false }
}, [])
return <MyComponent x={x} />
</code></pre>
In this example it's possible that component will be unmounted, then completion handler will run and try to modify state before cleanup function will be able to set the flag.<p>Imo choosing a different name for new useEffect would be better (like useAsyncEffect or introducing a parameter), because just changing its behavior won't even result in compilation errors or guaranteed run-time errors, only make old code unstable.<p>Is there a way to reliably detect if component is still mounted before updating it when doing async operations in effects?
I’m excited for no event pooling. I’ve been bitten by that a few times when refactoring.<p>Thought about making a lint for it but never got around to it.<p><a href="https://reactjs.org/blog/2020/08/10/react-v17-rc.html#no-event-pooling" rel="nofollow">https://reactjs.org/blog/2020/08/10/react-v17-rc.html#no-eve...</a>
It's refreshing to see a major release of a frontend library that doesn't completely redo the API (React Router and Angular, take note). I remember there was a time when a bunch of features were being considered to be bolted on to JSX which was going to be called JSX 2.0[0]. I'm glad that never happened. Maybe the next version of React can even remove features, like hooks.<p>0. <a href="https://github.com/facebook/jsx/issues/65" rel="nofollow">https://github.com/facebook/jsx/issues/65</a>
Was just thinking that we're probably due for a major release sometime now that Concurrent Mode seems to be starting to mature a little (disclaimer: it's still experimental, don't use it in production yet, etc.)<p>I'm sure the React team must be eager to get all the juicy changes out of the experimental branch and into the hands of developers. So it's great to see though that they're still taking their time to do it properly. Looking forward to seeing what come nexts :)
Hm. I like the idea of gradual upgrades in theory, but I worry the reality will be sites loading at least two versions of React semi-permanently. And possibly even worse, you end up with an NPM dependency nightmare of off-the-shelf component X using an entirely separate React runtime.<p>Yet more excess JS downloading and running on client devices, all in the name of superior developer experience. I hope my cynicism is proven wrong!
Jet, Angular 9 has such slow build times I can even imagine anyone would use it:<p><a href="https://github.com/angular/angular/issues/37293" rel="nofollow">https://github.com/angular/angular/issues/37293</a><p>I have 2 comparable applications (in size) and React build times are 10 times faster than Angular.