Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new wave of React state management

frontendmastery.com

Post reply on HN
Print view View original

41–50 of 310 posts

Re: The new wave of React state management

#41

Post by monroewalker »

acemarke wrote: post #35
Waterluvian wrote: post #6

I used Redux and loved it until I moved to typescript. Then there was a terrible amount of boilerplate and magic. So I wrote my own 75 line alternative that does a bare minimum. It’s basically just a useContext wrapper. And I haven’t looked back since. This is for pure client side stuff, of course.

Hi, I'm a Redux maintainer. FWIW, we specifically designed our official Redux Toolkit package to not only eliminate the general concerns about Redux "boilerplate" [0] [1], but also work great with TS. With our recommended RTK+TS usage patterns, a typical "slice reducer" file only needs to define a type for the reducer's state, and then define a case reducer as `(state, action: PayloadAction `) [2], and that's it. We'…

RTK is what made redux usable for me. I can't imagine using redux without it. ^ Mark is also very active and responsive in the Reactiflux discord and has directly helped me and countless others clear any hurdles with its use

Re: The new wave of React state management

#42

Post by kizer »

"Prop drilling". So many buzzwords. SSR, Hydration, Tree shaking, Hot module reload.

How has web development gotten here? It just seems to have evolved so much needless complexity to me.

Don't forget about web components! Integrated into the platform.

Re: The new wave of React state management

#43

Post by nikodunk »

For anyone struggling with the complexity and boilerplate of Redux, at my day job we added Redux Toolkit (the newly recommended add-on by the Redux project itself!) and it solves most of the verbosity issues! We use it to share all our state logic over mobile and web and it works excellently now. I'd actually recommend Redux w/ Redux-Toolkit, for the first time ever.

Re: The new wave of React state management

#44

Post by kitten_mittens_ »

etimberg wrote: post #16
jeroenhd wrote: post #7

I've used Redux but I've never heard of any of these alternatives. I have no doubt they're popular, but what is it about frontend that makes everyone reinvent the wheel every five years? Everything from the tooling to the tiny details somehow expires and gets recreated in a similar-but-not-similar-enough way that keeps the ecosystem in a constant state of flux. Is it the lack of platform API support? Is it the commun…

I think it's because redux is quite painful to use with very modern apps. Most of the time you need something like `redux-saga` or `redux-thunk` to deal with async side effects. I'm not sure which is the most popular today, but sagas are based on generators and trying to use those with typescript is very very painful and the underlying issue [1] is marked as a design limitation in TS itself. In addition, if you want…

arcanis has a PR to patch up the issue that's sat for a year plus now. https://github.com/microsoft/TypeScript/issues/43632

> In addition, if you want to have your app load as smaller chunks rather than a single large bundle, you need to be careful to ensure that things work even all the backing reducers aren't yet loaded.

In the decade old application we use redux saga in at work, a large portion of our 7MB minified/gzipped main chunk is redux handlers. It'd be nice if there was a relatively simple way to not synchronously load all the reducers up front.

Re: The new wave of React state management

#46

Post by johtso »

For me using xstate was a game changer. Pulling logic out into a state machine gives you so much clarity over your application logic. Also nice to have your business logic defined with something that is framework agnostic.

Re: The new wave of React state management

#47

Post by cercatrova »

fabian2k wrote: post #5

For me the issue of state management mostly went away after starting to use React Query. It turned out that the most problematic state was server-side state for me, which is handled very well by libraries built for that purpose. The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient. A lot of state can be local, and local state is easy to handle with…

Redux now has its own query solution as well, it's pretty useful [0].

[0] https://redux-toolkit.js.org/rtk-query/overview

Re: The new wave of React state management

#48

Post by nine_k »

doodlesdev wrote: post #27

I'm pretty sad this is the point we are at with React frontend development, the library is becoming much larger than it's original scope and it's getting bloated while not solving the essential problems that happen. In my opinion the best solution we have right now for frontend JS development is to not use JS or JSX at all and instead use a DSL such as Svelte, this way the compiler abstracts all complication and ther…

Svelte does wonders to code size, indeed.

But does it solve the problem of growing state which never gets GC'd when components which used to use it are gone? Does it solve the problem of only redrawing the required minimum (beside the normal VDOM approach)?

I'm asking as someone not knowledgeable enough about Svelte.

Re: The new wave of React state management

#49

Post by cehrlich »

fabian2k wrote: post #5

For me the issue of state management mostly went away after starting to use React Query. It turned out that the most problematic state was server-side state for me, which is handled very well by libraries built for that purpose. The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient. A lot of state can be local, and local state is easy to handle with…

Agree completely, React Query has made it so much easier to build any kind of app that deals with server state, stuff that would have been extremely challenging to write in the past is now just a couple of lines and works better than before.

I personally like using Jotai (if I just want a better version of React Context) or Zustand (if I need a bit more than that) for “client state” alongside React Query, but I’ve also built projects where I didn’t need a client state management solution at all.

Post reply on HN