Finally listened to the React 18 Working Group Twitter Space, and it provides a nice over of the plans/features coming in React 18!
Curious but busy? Check out my summary in 12 tweets~ 🧵
1/12 React 18 alpha was published, and has exciting new features. For now, you don’t need to read more unless you are curious and/or if you are a library author/educator who wants to get a head start. Details in the blog post - reactjs.org/blog/2021/06/0…
2/12 The React team has created a React 18 working group with the goal of providing support to, and getting feedback from, the React community and library authors in a transparent way. It’s a diverse and friendly group. Check it out if you are curious! github.com/reactwg/react-…
3/12 @aakansha1216 asked: What is this “automatic batching”?
Today, in some cases, such as inside of ‘setTimeout’ or a data fetch callback, React 17* does not batch 'setState' calls, so two 'setState' calls in a row would trigger two separate re-renders.
4/12 In React 18, all ‘setState’ calls will be batched, even if they are inside of a ‘setTimeout’ or data fetching callback, because this generally improves rendering performance. That is “automatic batching”. More info here - github.com/reactwg/react-…
5/12 @rickhanlonii Asked/answered: What/why/how to use the new concurrent features? First - in React 18, concurrent features are opt in. If you don’t opt in, nothing changes, and there is nothing to learn or worry about. That said -
6/12 Concurrent rendering is new ability in React - it knows how to render components in the background. To opt small parts of your app into concurrent rendering, you use ‘startTransition’ to wrap lower priority state updates. For example -
7/12 Updating the value of an input on keypress should be instant. But fetching and rendering a search results list can happen slower. Wrapping the results list update in ‘startTransition” tells React that update can be done “in the background”, at lower priority.
8/12 @MarkFunk asked what the difference is between the two 'startTransition' APIs. tldr; The hook gives you a 'pending' state which tracks that particular call of the 'startTransition' hook. More info on 'startTransition' here - github.com/reactwg/react-…
9/12 @brian_d_vaughn shared how the React DevTools will be improved to show more information related to the new React features, like showing which components are suspended with Suspense, or what components are being rendered at a lower priority.
10/12 @chantastic Asked - What's the "research" process for the React team?
* Design new features based on first principles and good UX.
* Give new stuff to FB eng. first, and iterate quickly.
* Release to OS once it's "solid", with alpha, beta, RFC, etc.
11/12 Lots of credit/shout outs to great folks! @tomocchino for leading React core since before it was React core. @cassidoo for giving feedback which inspired creating the React 18 WG. @acdlite for hosting. @sophiebits for key contributions over the years. Too many to name!
12/12 This concludes the summary of the React 18 WG Twitter space. Find the full recording here* and look out for more news on React 18 over the coming months. Woot!
*
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Hey you! Don’t use #React useCallback (or useMemo) for all your callback props, thinking it will improve performance, because it won’t. Here's why - 1/n
For every #React `useCallback` call you make, the browser does some work. For a a simple callback, with a fast component, adding the `useCallback` has little or no benefit, and even has a little performance cost. 2/n
@kentcdodds explains this in “When to useMemo and useCallback” - (kentcdodds.com/blog/usememo-a…) and yet I still run into people saying “We should be wrapping <misc callback> in `useCallback`” arbitrarily, with the mistaken notion it will improve performance. 3/n