16 ms·

React v18.0

• traspler 5y ago
  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?
  • rickhanlonii 5y ago
    We don't expect most users will interact with the `startTransition` API directly. Instead, it will be built into routing libraries and other infra code so you get the benefit of transitions without need to wrap all the state updates yourself.
• aleksjess 5y ago
  @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?
• herrkanin 5y ago
  Congratulations to the React team! I remember three years ago when Dan first showcased some of the concurrent features [1], so this has been quite long in the making. [1] https://www.youtube.com/watch?v=nLF0n9SACd4 https://www.youtube.com/watch?v=nLF0n9SACd4
• nikivi 5y ago
  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 https://www.solidjs.com is quite awesome but lacks the React ecosystem.
  • acemarke 5y ago
    Andrew Clark suggested recently that chunks of the event system may be removed in the next major: https://twitter.com/acdlite/status/1505378980878331909 https://twitter.com/acdlite/status/1505378980878331909
  • RadixDLT 5y ago
    this is where they drop support for IE https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#dropping-support-for-internet-explorer https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.h...
  • traspler 5y ago
    Doesn‘t Preact do that? (in regards to the Synthetic Event System)
  • deleted 5y ago
    [deleted]
  • o_m 5y ago
    They are dropping IE support with this version
    • MBCook 5y ago
      Shoot. You’re right. Here’s the quote from a preview release: “In this release, React is dropping support for Internet Explorer, which is going out of support on June 15, 2022. We’re making this change now because new features introduced in React 18 are built using modern browser features such as microtasks which cannot be adequately polyfilled in IE. If you need to support Internet Explorer we recommend you stay with React 17.” (Shoot because I have to support IE still.)
      • The_rationalist 5y ago
        What is their use case for microtasks?
        • 5y ago
• lefrenchy 5y ago
  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 5y ago
    Do transitions help with that? As I understood it, the batching changes would solve that problem and not necessarily the transitions.
    • lefrenchy 5y ago
      You're correct. They're so close to each other in the release notes I got them confused for a second!
• tunesmith 5y ago
  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.
  • acemarke 5y ago
    Enzyme has been lagging in support for React features for several years now, so yes, I would expect it would not correctly support React 18 right away. (Note that both Enzyme and React Testing Library are independent of what test runner you're using - Jest, Mocha, etc).
    • rkuykendall-com 5y ago
      > I would expect it would not correctly support React 18 right away It's worse than you know, Enzyme will never support React 18, and it will likely never officially (or fully) support React 17. It's a completely dead project.
      • vosper 5y ago
        This right here. Enzyme’s dead, barring some major change, and people need to move off it. https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl (Honestly I’m a bit surprised some big company hasn’t taken over Enzyme development - there most be teams facing hundreds ,or thousands, of hours on test rewriting)
      • rimunroe 5y ago
        Last I checked it still doesn't even fully support React 16
  • tshaddox 5y ago
    Regarding styled-components and many similar CSS-in-JS libraries, I don't think there are any breaking changes currently with React 18, but it does seem like the writing is on the wall that React intends to not support libraries that inject styles into <style> tags, or at least has some specific rules these libraries need to follow to avoid performance problems. See this discussion: https://github.com/reactwg/react-18/discussions/110 https://github.com/reactwg/react-18/discussions/110
• paxys 5y ago
  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 5y ago
    Next.js et all really lit a fire under React in this area. Glad to see React moving in that direction.
• rock_hard 5y ago
  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!
• acemarke 5y ago
  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 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.
  • mikewhy 5y ago
    > no more separate types package woo! and a module to augment!
  • rememberlenny 5y ago
    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.
    • shoulderfake 5y ago
      Mark is by far the most selfless oss maintainer I've come across. Hats off.
  • kovek 5y ago
    IIRC mobx is much easier to use than Redux. Any thoughts on this?
    • acemarke 5y ago
      Mobx and Redux Toolkit have some relatively similar capabilities. It largely depends on whether you prefer FP-style code and explicit logic (Redux), or OOP-style code and implicit update behavior (Mobx). Any particular aspects of Mobx you feel are easier to use, or parts of Redux you feel are harder? FWIW if you haven't looked at Redux recently, it's changed dramatically in the last couple years. "Modern Redux" with Redux Toolkit and the React-Redux hooks API is _much_ easier to use than the older-style "hand-written" patterns. With RTK, there's no `const ADD_TODO = "ADD_TODO"`, separate action creators, or object spreads for immutable updates. RTK's `createSlice` auto-generates action creators for you, and includes Immer for "mutating" immutable updates in reducers. You can see the differences in our rewritten Redux docs tutorials: - https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... - https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... Also note that last year we released a new RTK Query data fetching and caching API that's included in Redux Toolkit, which is a full-featured data caching abstraction. Define some API endpoints, get React query and mutation hooks automatically: - https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... - https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview To be clear, Mobx is a great library, as are other packages like Zustand, Jotai, XState, and React Query. You should use whatever works best for your own use cases and preferences. But, it's also true that most people's opinions of Redux are based on the older patterns that have been obsolete since 2019, and we get a ton of highly positive feedback about RTK on a daily basis, with people telling us how much they love to use it.
• ddaalluu2 5y ago
  Congratulations, but to me React is like Rust. Something I always wanted to get into but found better alternatives. In the react case Vue wins for me and in the Rust case it's Go. I really tried, time and time again to like it and write something with it, but Vue just offers the better libraries. Altough with the recent 2 to 3 upgrade and pinia instead of vuex I'm starting to get dissatisfied with the "no single proper way" of Vue. Vuex-orm being the best frontend REST wired ORM, nothing comes close to ease of use and setup. Meanwhile react has what? Complicated redux, or is that even a thing anymore? Idk, which I would. Redux the boilerplate abomination. That's exactly what drove me away from Angular. But I'm starting to rant again. And react has even more of the "not a single proper way". Yeah I know, nextjs the magic bullet, but what if you don't agree with pretty much everything about it, starting with routing.
  • Ralfp 5y ago
    If you are looking for api client library that has automatic updates propagation in the UI, condider giving Appollo Client and GraphQL a try. …but I am finding lack of client library for React implementing eg. Open API protocol hard to believe. Is that true?
    • eropple 5y ago
      React and OpenAPI are orthogonal things. You'd build a JavaScript/TypeScript library for talking to an API, not a React one. (Generally, though it adds some friction unless you have HTTP servers with libraries to help you out, I prefer this approach whenever possible to GraphQL. Mostly because relying on frontend folks to inflict terrible damage to databases via wild abuse of resolvers is not my cup of tea, but as GraphQL tools become smarter I'm coming around on this a bit.)
      • Ralfp 5y ago
        Well, yeah, but OP claims doing REST client with react is something hard.
  • acemarke 5y ago
• neals 5y ago
  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.
  • goodoldneon 5y ago
    If you'd like to migrate them, the React team maintains some awesome codemods: https://github.com/reactjs/react-codemod https://github.com/reactjs/react-codemod
    • Beowolve 5y ago
      I still wish they maintained ESLint rules to help auto fix things instead of codemods.
  • deleted 5y ago
    [deleted]
  • zdragnar 5y ago
    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.
    • deleted 5y ago
      [deleted]
  • TurningCanadian 5y ago
    FYI IntelliJ/WebStorm has a refactor option that automatically converts class-based components to hooks and vice-versa.
    • 5y ago
• danabramov 5y ago
  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 https://twitter.com/reactjs/status/1508838714180612100
  • have_faith 5y ago
    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
    • danabramov 5y ago
      Strict Mode docs are probably the best place, yes. If you have a question that isn't answered there, feel free to raise an issue in the React repo and we'll try to help.
• yewenjie 5y ago
  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.
  • vosper 5y ago
    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”.
  • danabramov 5y ago
    “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.
  • deleted 5y ago
    [deleted]
  • nop_slide 5y ago
    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.
    • danabramov 5y ago
      Over time, we expect that in most cases you wouldn’t use it directly. Instead, a router might use it for route changes, for example, automatically marking them as transitions. This would make it possible for the user to click a link in the middle of rendering, and immediately handle it instead of being blocked until the render completes.
• pier25 5y ago
  I wonder how it will compare to v17 on the JS benchmarks. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
• I_am_tiberius 5y ago
  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 5y ago
    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.
    • I_am_tiberius 5y ago
      Thanks for your response. Sorry, I didn't report it but will do next time. Thanks for your great work by the way!
• journey_16162 5y ago
  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.
  • fabian2k 5y ago
    React will nag you to give the array elements unique keys so that it can track them. If you do that, it will generally be able to avoid manipulating the DOM for those elements of the array that did not change. It will still render (= execute the JS of the component) all of them by default, how expensive that is depends entirely on the content of your components. If that is a problem you can use React.memo() to prevent rerendering of those components if their inputs did not change.
    • wereHamster 5y ago
      Well, it's only efficient if the component which renders each element in the list gets a stable key AND is React.memo() AND the props passed to the components do not make the React.memo() pointless. For example the following will not be particularly efficient, because a fresh callback is passed to the component on each render. <> {array.map((data) => ( <SomeComponent data={data} onClick={() => { alert('nope'); }} /> )} </>
      • fabian2k 5y ago
        That's what useCallback is for. And it really depends on how heavy the child components are on whether all this makes a noticeable difference.
  • brundolf 5y ago
    React will iterate over the whole array again (the array causes the container component to re-render, and its contents including the JSX are just JS that gets run again), but the individual components rendered from the array can prevent their own internal render logic from being called again unnecessarily by using React.memo
• Stoids 5y ago
  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.
  • swyx 5y ago
    jsconf iceland was 4 years ago, not 3 years :) been a looooong wait https://youtu.be/nLF0n9SACd4 https://youtu.be/nLF0n9SACd4
  • charlie_hebert 5y ago
    If your team's using React Router, there's an upcoming release that aims to address the problem you describe (taken from Remix, as it's by the same guys): https://remix.run/blog/remixing-react-router https://remix.run/blog/remixing-react-router
    • Stoids 5y ago
      Thanks for the link! Hadn't seen that release, looks promising. I think this could definitely work for some of our newer apps that haven't fully bought into GraphQL yet. Not sure if the loader / action prop callbacks will be sufficient when you start getting into more complicated GraphQL use cases around caching. Haven't played with it though, so might be wrong! Good to see that these will already be in place for the community to leverage.
• maxfurman 5y ago
  Yet again, another React major version, more churn in the ecosystem. Are all of the libraries your app depends on compatible with the new version? How much effort to update the ones that aren't, if that's even possible? Get ready to spend tens of your team's man-hours answering these questions.
  • hsavit1 5y ago
    what is the point of this comment? would you prefer react never receive any updates? AFAIK transitioning to react 18 shouldn't break much unless you want to take advantage of concurrent mode
  • ng12 5y ago
    Ah yes, I often forget that the JavaScript ecosystem invented versions. We really should have taken a page from literally every other programming framework that has never had these problems.
  • nkohari 5y ago
    React v17 was released in October 2020.
  • seattle_spring 5y ago
    Dang kids and their versions!
• deleted 5y ago
  [deleted]
• wetpaws 5y ago
  Starting from the introduction of hooks all react updates have been going backward. The biggest benefit of react for me always been it's brutal conceptual simplicity. It's been a reliable tool and now it turned into the monster.
  • danabramov 5y ago
    It's a fair criticism! From our point of view, this is not really true if you consider the scope of the problems that are being solved. Sure, React itself was very simple, but implementing common patterns (like code splitting, coordinating loading indicators) was difficult, and some things (like streaming HTML while waiting for data) were downright impossible. If you compare React today vs old React + all the stuff you have to add for this, you might find that React today gains a lot of powerful features from very few primitives (like startTransition and Suspense). It might read densely in a blog post though, I get that.
  • ng12 5y ago
    Hooks have made my life simpler. HoCs were a nightmare and I'm glad to be rid of them.
  • ZephyrBlu 5y ago
    Hooks are conceptually much simpler than lifecycles.
• jerrygoyal 5y ago
  I was really hoping that they would have internal implementation by now to automatically infer the missing dependencies array for hooks so we need not rely on an external linting tool. This is one of the most common issues faced by react devs.
  • acemarke 5y ago
    The prototype "React Forget" compiler may hopefully solve that use case: - https://youtu.be/lGEMwh32soc https://youtu.be/lGEMwh32soc - https://www.reddit.com/r/reactjs/comments/rcn5ks/react_forget_compiler_automated_memoization_react/ https://www.reddit.com/r/reactjs/comments/rcn5ks/react_forge...
• bitwidget 5y ago
  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.
• ihuman 5y ago
  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."
• StopDarkPattern 5y ago
  "The most important addition in React 18 is something we hope you never have to think about: concurrency." - really? this is what our technical prowess has come to?
  • Spivak 5y ago
    Creating an abstraction that allows you to write seemingly imperative code but have it actually executed concurrently is a huge technical achievement in any area. “Fearless” concurrency is the only concurrency paradigm that scales and no one has solved it.
• nojvek 5y ago
  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.
• brynjolf 5y ago