https://www.solidjs.com is quite awesome but lacks the React ecosystem.
https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.h...
react itself is also tiny; it only adds 2.5kb to your bundle size [2] (a 300b reduction from v17). react-dom is the much larger dependency, although as of right now Bundlephobia errors out when trying to analyze the newest version [2].
EDIT: they’ve got react-dom@18.0.0 working now and it’s indeed slightly bigger than the previous version: 41.7kb vs 39.4kb.
“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.)
> 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.
The beta React docs _still_ don't even document the useEffect hook.
edit: You can go both ways, if your class component is simple enough.
I did upgrade from react-router v1 though... declaring routes as JSON just felt a bit too gross.
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.
Also, is there something about MUI and react18 that makes styled-components more of a pain? Not sure where I heard that.
The writing on the wall is more that we wouldn't encourage this mechanism over time because we find that <link> + inline styles have much better performance tradeoffs. Often, it's possible to implement a very similar API but statically extractable. That's great and we encourage that. But we wouldn't add a runtime helper like css() into React because we don't think this pattern scales well. Of course, we can't stop people from using it though.
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.
However, we've worked closely with the React Testing Library maintainers, and that's the solution I'd recommend for React tests going forward. We're fans of RTL because it encourages you to write tests "end-2-end"-like tests that resemble real-world scenarios and are resilient to implementation changes.
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.
Vue is certainly easier to learn, and comes with a lot of oficial libraries such as vuex, Vue router etc. But that's all about it.
The Vue 2 to 3 transition is a big fuck up, python level. One of the companies I've worked for will never be able to migrate to Vue 3, because they cannot afford to stop product development and they also have a ton of external dependencies that are mostly abandoned.
The integration with typescript, even in Vue 3 is still not as good as it is for react. This is critical for large projects, and to have proper ide autocomopletion, etc.
Then the ecosystem....it is a lot smaller than the React ecosystem.
Then the "meta frameworks". Next.js is infinitely better and better managed than Nuxt, which went full rewrite and again, from my point of view that's a big fuck up.
And finally, I have absolutely nothing against other languages (even English is not my native language) but I got really tired of finding myself debugging problems and ending up in issues, forums or readmes in languages that are not English (mostly Chinese).
React has its drawbacks, but I prefer those by a far amount to the drawbacks of using Vue.
That's funny. To me it's the other way. I love both React and Rust. Vue and Go both seem like tools that get halfway to the benefits of React/Rust and would be good choices if React and Rust weren't available.
> Meanwhile react has what? Complicated redux, or is that even a thing anymore? Idk, which I would. Redux the boilerplate abomination.
There is now redux-toolkit, an official part of the redux project that provides a standard convention and helper within redux that reduces that boilerplate. There's also mobX which is more like Vue's state management. Both are well supported.
If you're happy with Vue, great! If you do get a chance, though, please take a look at the Redux docs tutorials to see how we teach writing "modern Redux" code today:
https://redux.js.org/tutorials/essentials/part-2-app-structu...
In case you want to try rust and react together:
…but I am finding lack of client library for React implementing eg. Open API protocol hard to believe. Is that true?
(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.)
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.
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-re...
- 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-b...
- 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.
woo! and a module to augment!
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.
Oh yeah definitely. For history nerds, I've included a bunch of old (but relevant) PRs in the full changelog so that you can see the evolution. For example:
>Add useTransition and useDeferredValue to separate urgent updates from transitions. (#10426, #10715, #15593, #15272, #15578, #15769, #17058, #18796, #19121, #19703, #19719, #19724, #20672, #20976 by @acdlite, @lunaruan, @rickhanlonii, and @sebmarkbage)
See https://github.com/facebook/react/blob/main/CHANGELOG.md. I also wrote a thread about some of the lessons learned: https://twitter.com/dan_abramov/status/1402927593406582787. Might make a full-fledged recap post at some point.
>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.
We've postponed it because there were some gaps we need to figure out. But it's likely coming in one of the minor releases.
>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".
Hear, hear. The reason we suggest that is that implementing refetching in the data layer is currently too challenging. Relay implemented it, but it is pretty opinionated about other things so it's easier for Relay. Next.js doesn't currently support refetching for getServerSideProps anyway, so it wouldn't be a regression. But for a generic non-framework API, this feature is very important. We're working on a cache mechanism that might solve this, but it's work in progress and it's hard to provide guarantees that it'll ship in the same form as it is now. We just don't have all the answers yet.
I hear you on the data fetching and always appreciate your teams' cautious approach. It gives me a lot of confidence in the APIs you all end up landing on, and I appreciate the focus on backwards compatibility and incremental upgrading as opposed to shipping out the first iteration of a cool idea that comes to mind. I know just enough about React to probably shoot myself in the foot with this type of stuff, but add in the idea of concurrency and all that likely falls over.
I think the story here with Relay and GraphQL is really awesome. I hope the Relay team has an article in the future showing off some of the possibilities—I think it makes a really strong argument for itself in conjunction with these features, even taking into account the restrictions you mention. Showing how some of these features flesh out in a more complete framework would be helpful in framing them in a vacuum. Or maybe I'll stop complaining and explore and write something myself!
For more details, see:
- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
If that is a problem you can use React.memo() to prevent rerendering of those components if their inputs did not change.
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'); }}
/>
)}
</>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.
- https://youtu.be/lGEMwh32soc
- https://www.reddit.com/r/reactjs/comments/rcn5ks/react_forge...
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!
https://krausest.github.io/js-framework-benchmark/current.ht...