WingNews logo WingNews GitHub [2]
top | item 30844414

React v18.0

489 points| pspeter3 | 4 years ago |reactjs.org | reply

129 comments

order
[+] acemarke|4 years ago|reply
Awesome! Glad this is finally out, and really looking forward to seeing what features the React team adds in follow-up releases.

The Working Group model really helped us in the community give feedback - APIs like `useSyncExternalStore` wouldn't have happened otherwise, and I really appreciate the responsiveness on that topic.

FWIW, React-Redux v8 is in beta right now:

- https://github.com/reduxjs/react-redux/releases

I think it's basically ready to go, but I haven't had a chance to really test out the SSR support I added a couple months ago. I'd love to have some help testing that out.

v7 will _run_ with React 18, but v8 has been specifically reworked to behave correctly when used with React's new "Concurrent Rendering" capabilities. We've also converted React-Redux itself to TS (no more separate types package).

Ideally, I'd like to release v8 as final in the next week or two.

[+] rememberlenny|4 years ago|reply
Thank you Mark for your selfless work to push this project forward. RTK Toolkit was an absolute game changer and has been a foundation that our product would suffer immensely without.
[+] kovek|4 years ago|reply
IIRC mobx is much easier to use than Redux. Any thoughts on this?
[+] mikewhy|4 years ago|reply
> no more separate types package

woo! and a module to augment!

[+] nikivi|4 years ago|reply
I wish React removed all the compatibility code it has with Internet Explorer and the likes and worked on minimising the weight. Also the synthetic events reactivity system seems a bit outdated.

https://www.solidjs.com is quite awesome but lacks the React ecosystem.

[+] rickhanlonii|4 years ago|reply
We plan to do this in a close follow up release! Automatic batching was one important step, because it starts to treat native events the same as events that goes through the synthetic event system. The rest will be a bigger breaking change for some folks though, so we didn't want to include it in this release, which is focused on giving users a smooth upgrade to start using concurrent features.
[+] afavour|4 years ago|reply
Yeah, the size of React still bugs me when Preact shows you can do 90% of the same stuff with a tiny fraction of the code.
[+] o_m|4 years ago|reply
They are dropping IE support with this version
[+] traspler|4 years ago|reply
Doesn‘t Preact do that? (in regards to the Synthetic Event System)
[+] yewenjie|4 years ago|reply
React is not only introducing layers and layers of abstractions/ concepts that are hard to grasp for a newcomer, they are also reclaiming well-established terms.

> A transition is a new concept in React to distinguish between urgent and non-urgent updates.

> Urgent updates reflect direct interaction, like typing, clicking, pressing, and so on. > Transition updates transition the UI from one view to another.

[+] danabramov|4 years ago|reply
“State transition” is a well-established concept, which applies here. We’re also planning to eventually integrate this feature with animations, which would match the other meaning of “transition”. This is why we settled on this term. We get similarly criticized when we come up with our own names for features, so it’s a tricky balance.
[+] pandesal|4 years ago|reply
I don't get how "layers and layers of abstraction/concepts that are hard to grasp for a newcomer" is your critique here? The literal entirety of tech is layers and layers of abstraction. Also, just because the improvements or new concepts are going to be difficult for newcomers to grasp doesn't mean they are objectively bad. The fact that things are going to be difficult for newcomers should not be an impeding factor on whether or not to build upon existing features. There are ways for newcomers to build up their way to eventually learn the advance concepts. Newcomers are not forced to go from 0-100 on day 1
[+] vosper|4 years ago|reply
I’m pretty sure they’re not claiming to have invented transitions. They maybe should have said “a new concept to React” rather than “a new concept in React”.
[+] haolez|4 years ago|reply
In this specific context, can Preact be considered a more "reasonable" React offering? Or does it follow each and every feature of React?
[+] nop_slide|4 years ago|reply
I'm also confused by the `useTransition` idea, to be honest I don't exactly know when or where I would use it after reading about it. Sounds like a specific optimization tactic.
[+] thex10|4 years ago|reply
And, more irksome to me, they don't keep their docs up to date.

The beta React docs _still_ don't even document the useEffect hook.

[+] neals|4 years ago|reply
Fun fact: I started building a couple React apps 5 years ago. Apps still run, but since they're class based component and don't use hooks, the apps feel like ancient. They run perfectly fine though. New guys don't really want to work on in though. Hooray for progress.
[+] TurningCanadian|4 years ago|reply
FYI IntelliJ/WebStorm has a refactor option that automatically converts class-based components to hooks and vice-versa.
[+] franciscop|4 years ago|reply
For few hundred $ you can get that converted to hooks, depending on the app complexity. I'd offer it myself if I didn't have a fulltime job currently.
[+] ab-dm|4 years ago|reply
Same. Every time a new version gets released I feel a pang of guilt for that poor codebase, but it's been jogging along for 5-6 years with minimal updates and it works like a charm. Fairly big code base as well.

I did upgrade from react-router v1 though... declaring routes as JSON just felt a bit too gross.

[+] zdragnar|4 years ago|reply
Fun fact: very few developers (especially newbies) enjoy working on legacy projects.

New features push the business forward, lets you learn faster, you aren't constrained by the garbage someone else wrote years ago but don't have the budget to change, and it looks better on a resume in an industry where the average term of employment is 2 years because new hires get bigger pay bumps than annual raises give.

[+] danabramov|4 years ago|reply
We've also posted a tweet thread breaking down the main features, so please check it out if you enjoy that format! https://twitter.com/reactjs/status/1508838714180612100
[+] have_faith|4 years ago|reply
Interesting to read about React purposefully doing a double render in dev mode to try and flush out some of the anti patterns, patterns that I know that I am sometimes guilty of. Is the strict-mode docs the best place to read about this kind of thing? the intersection of custom hooks and concurrent mode specifically
[+] Stoids|4 years ago|reply
Congratulations to the React team on the release! I've kept up somewhat with the development of these features since Dan first introduced some of the ideas at JSConf 3 years ago. It's interesting to see how the APIs have changed over time—I'm sure as a result of some tough lessons learned at Facebook.

As someone who has worked on large React projects worked on by multiple teams, I can see a lot of the value proposition being delivered in this release. I can already think of many places where I'll want to slot in the transition API.

I'm curious if the SuspenseList API is making the cut here or if it's still on the roadmap? I played with it a while back and thought it was very cool, albeit slightly niche perhaps.

The only part that's a bit of a bummer is the recommendation on using suspense for data fetching. I'm already itching to get rid of lots of if (loading) {} code that plagues many of our components and makes orchestration and re-use of them a bit more painful than we'd like. I see lots of power in the idea of suspense as a way to orchestrate various generic async operations, but it feels like they don't want us to build solutions on this abstraction unless we buy into some opinionated framework. I can't really tell my team "let's use remix now lol".

All that being said this is a tremendous step forward and I'm looking forward to seeing what problems the React team tackles next.

[+] nojvek|4 years ago|reply
I wonder how concurrent mode in React stacks up with Solid.js. It seems React has been adding more and more features + complexity, while other frameworks are re-thinking the approach from the ground up building a simpler and faster primitive, yet keeping the same jsx primitives.
[+] tunesmith|4 years ago|reply
We've heard rumblings that react18 implies the need for major changes in legacy projects. For instance, jest testing suites apparently need to move away from enzyme?

Also, is there something about MUI and react18 that makes styled-components more of a pain? Not sure where I heard that.

[+] rock_hard|4 years ago|reply
Amazing news…congrats to the React team!

We have been running the RC in prod since January and it’s been super smooth

Concurrent mode makes react apps much, much faster and snappier…huge win for perf!

[+] paxys|4 years ago|reply
Exciting to see so much server-side focus in all recent development. IMO React has massive value outside of the usual static site or SPA making API calls use cases. Eagerly waiting for Server Components to get ready.
[+] nathancahill|4 years ago|reply
Next.js et all really lit a fire under React in this area. Glad to see React moving in that direction.
[+] ihuman|4 years ago|reply
When is the Suspense documentation going to be updated? I don't see it in the beta docs, and the main documentation page is for v17, so its still marked as experimental. It also says that, "Before React 18 is released, we will replace this page with stable documentation."
[+] lefrenchy|4 years ago|reply
Really excited about the transitions (edit: I mean batching) for state updates. I always found it so frustrating that updating 3 different state values in a callback would cause 3 separate renders.
[+] traspler|4 years ago|reply
Do transitions help with that? As I understood it, the batching changes would solve that problem and not necessarily the transitions.
[+] journey_16162|4 years ago|reply
If you have a list of elements rendered in a container (from array), does React always re-render the whole thing (contents of container) when adding / removing elements from the array or is there a way to work around that? I'm coming from Svelte, I would not be learning React if it was not for its omni-presence in the job market and I'm genuinely curious.
[+] acemarke|4 years ago|reply
Yes. React re-renders components recursively by default. So, any state update in a parent component will recurse through and render all child components. But, a "render" does not necessarily imply a "DOM update" - it's about asking the components "what do you want the UI to look like now?", and determining _if_ updates are needed. This can be optimized if needed.

For more details, see:

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

- https://www.zhenghao.io/posts/react-rerender

[+] I_am_tiberius|4 years ago|reply
I hope backwards compatibility is good. A release candidate of React 18 I tried has caused installation issues in combination with dnd-kit utilities.
[+] danabramov|4 years ago|reply
Sorry to hear that. Did you report the issues? Generally it's hard to fix bugs in a release candidate if the bugs get unreported. If you file a bug we can have a look.
[+] aleksjess|4 years ago|reply
@danabramov would you mind sharing the rationale behind making the ReactWG invite only? I understand that, de jure, it's Facebook's property, and you all can do whatever you want with it. De facto, since so many people on the outside world contributed to the project, at least an election of a commission would have been warranted. Would you mind commenting?
[+] bitwidget|4 years ago|reply
I'm most excited about the suspense feature since handling load was always a bit of extra code when it pretty common among most apps.
[+] traspler|4 years ago|reply
The Transitions look nice but I feel like this will bloat code incredibly. Maybe it‘s meant only as an optimisation to be used sparingly but if I would always have to also start a transition when I do some conditional rendering it will generate a lot of overhead code. Or am I wrong?