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.
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.<p>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.<p>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.
I use React (well, Preact) every day.<p>I use it 2014-style. Class-based components, componentWillMount, render, callbacks, and that's about it.<p>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.<p>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?
Really looking forward to new server side components and suspense.<p>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.<p>Thanks again! And keep up the good work.
Automatic batching appears to cause problems, because the screen doesn't update when it needs to.<p>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.
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.
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.
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?
Two things about React will never stop being funny to me,<p>1. An entire generation of front end developers have staked their careers on a framework developed by Facebook. Facebook!<p>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.