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

31–40 of 310 posts

Re: The new wave of React state management

#31

Post by petilon »

wilde wrote: post #26
petilon wrote: post #14

Earlier quoted context omitted.

All you need is a client-side cache.

How do changes to that cache get displayed? Your cache emits events that each UI element has to listen to? Congrats you’re using redux! (It would perhaps be more accurate to say that React folks had to reinvent these patterns, but the problems were definitely present in the postback era)

> Your cache emits events that each UI element has to listen to?

It doesn't. How often do you have the same information redundantly displayed in multiple places, on the same screen?

Re: The new wave of React state management

#32

Post by lhnz »

petilon wrote: post #14
wilde wrote: post #12

Earlier quoted context omitted.

This is true until your customers complain that your UI is super slow. You realize they’re trying to use your app from a cell phone with poor service. So you have the genius idea to add optimistic updates in JS. Now you have all the problems from the article since you need to update all the components everywhere on screen that share state.

All you need is a client-side cache.

That is exactly what the React state management solutions all are...

Re: The new wave of React state management

#33

Post by geraldwhen »

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…

You need redux saga because api interactions can be complex.

I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display.

But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy.

Oh, and product now wants to make sure we capture some random third party tracking event in between specific state changes. The ui MUST NOT change until the tracking call succeeds.

This and more is trivial in redux saga, and you can write tests around it.

Re: The new wave of React state management

#35

Post by acemarke »

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've put a _lot_ of work into making sure that our library TS types minimize the amount of types that you have to write in your own app code.

Also, one of the reasons we now teach the React-Redux hooks API as default is that it's drastically easier to use the hooks with TS than the legacy `connect` API.

If you haven't had a chance to see what "modern Redux" looks like, I'd suggest going through our docs tutorials to see how we want people to learn and use Redux today [3]

[0] https://redux.js.org/introduction/why-rtk-is-redux-today

[1] https://blog.isquaredsoftware.com/2022/06/presentations-mode...

[2] https://redux.js.org/tutorials/typescript-quick-start

[3] https://redux.js.org/tutorials/index

Re: The new wave of React state management

#36

Post by celim307 »

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…

React query is one of the highest quality react libraries I’ve ever used

Re: The new wave of React state management

#37

Post by acemarke »

geraldwhen wrote: post #33
etimberg wrote: post #16

Earlier quoted context omitted.

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…

You need redux saga because api interactions can be complex. I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display. But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy. Oh, an…

For the record, we actually have recommended _against_ using sagas in most cases for a long time now, and especially for data fetching.

Today, our recommendations are:

- Data fetching: default to using RTK Query, fall back to thunks if needed

- Responding to actions or state changes: use the new RTK "listener" middleware as the main approach

See my recent talk "The Evolution of Redux Async Logic" for details:

- https://blog.isquaredsoftware.com/2022/05/presentations-evol...

as well as my recent presentation going through "Modern Redux with Redux Toolkit":

- https://blog.isquaredsoftware.com/2022/06/presentations-mode...

Re: The new wave of React state management

#38

Post by cercatrova »

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.

Context and Redux are somewhat different tools and context doesn't necessarily solve the same problems as Redux. This article by the maintainer of Redux (acemarke) goes over why (looks like he replied to you as well) [0]. Have you tried Redux Toolkit as well? It cleans up a lot of the complexity of Redux and works well with TypeScript [1].

[0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

[1] https://redux-toolkit.js.org/

Re: The new wave of React state management

#39

Post by bernawil »

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…

  The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient
hah this is an understatement. For hooks, the React runtime already does a ton of non-standard-js things under the hood. useState gives a method to update and "subscribes" a component to updates on the hook's value. Put that code in a custom hook, export it and you re-invented Redux. In fact, exporting a single big useReducer for all your state gives you something almost identical to old style Redux.

Re: The new wave of React state management

#40

Post by acemarke »

bernawil wrote: post #39
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…

The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient hah this is an understatement. For hooks, the React runtime already does a ton of non-standard-js things under the hood. useState gives a method to update and "subscribes" a component to updates on the hook's value. Put that code in a custom hook, export it and you re-invented Redux. In fact, exp…

FWIW, there _are_ a number of technical and conceptual differences between Context+`useReducer` and Redux. I wrote an extensive post describing those differences and potential use cases for each:

https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

Post reply on HN