The new wave of React state management

Post by jcelerier » Sat, Jul 02, 2022, 5:26 PM UTC

sph wrote: post #55

dageshi wrote: post #15

After reading the "Grug Developer" article recently, I've been thinking of frontend development as "The Plane of Eternal Complexity Demons".

It makes me smile that elsewhere in this thread there's people saying "I've been using and state management is now super easy." when you know in two months people will be saying that library is over-engineered and someone will suggest to try the new panacea that will solve all of your problems, for real this time. Such is the hype cycle of frontend development.

Post by acemarke » Sat, Jul 02, 2022, 5:28 PM UTC

phreack wrote: post #80

nikodunk wrote: post #43

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.

There's a library called rematch that's been implementing most of these ideas for a long time, but sadly it didn't get popular enough and it seems to be somewhat lacking maintenance. It was such a pleasure to use (in comparison) that I just can't believe how people ever work with those massive switch statements.

Post by cageface » Sat, Jul 02, 2022, 5:37 PM UTC

acemarke wrote: post #37

geraldwhen wrote: post #33

Earlier quoted context omitted.

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…

Post by geraldwhen » Sat, Jul 02, 2022, 5:40 PM UTC

acemarke wrote: post #37

geraldwhen wrote: post #33

Earlier quoted context omitted.

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…

Post by azemetre » Sat, Jul 02, 2022, 5:42 PM UTC

rebelos wrote: post #57

melony wrote: post #9

Most of these new client side state management libraries are incompatible with any form of SSR. If you see the documentation for Jotai/Zustand/Valtio, the solution is to avoid using with Next.js at all, or fall back to hacks using context+provider at which point the state manager becomes effectively redundant.

Isn’t SSR only really relevant when you need to optimize for SEO (which only applies to a subset of apps)? Seems like it doesn’t confer any other significant benefit.