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

161–170 of 310 posts

Re: The new wave of React state management

#161

Post by bayesian_horse »

cosmiccatnap wrote: post #121

I find it interesting that across a decade and countless frameworks from jQuery, meteor, angular, and now react the core problem is still and somehow progressively worse than ever...state. I find it strange this is still such a hard problem to solve in an environment with a slew of options for key value global, local, and remote storage

It's easier to solve it than to agree on what is the solution and to keep it. The more alternatives to redux there are, the higher the chance you get thrown into projects with some lesser known framework, maybe not even used to its best.

Re: The new wave of React state management

#162

Post by ggregoire »

acemarke wrote: post #156
ggregoire wrote: post #147

Earlier quoted context omitted.

Exact same experience here. We were using Redux to manage server-side data and switching to React Query massively simplified everything. It appears that managing server-side data in an efficient way is an insanely complicated topic and React Query just solved everything about it that I can think of.

Yeah, both the React Query and Redux maintainers agree that you shouldn't be writing data fetching and caching logic yourself. That's why we recently added a new "RTK Query" data fetching and caching API to Redux Toolkit, so that if you're using Redux it handles that work for you: - https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... - https://redux-toolkit.js.org/rtk-query/overview and if you're just usi…

Yes we chose Redux 6 years ago for data fetching and caching when there wasn't as many alternatives as today!

Re: The new wave of React state management

#163

Post by weeksie »

acemarke wrote: post #153
weeksie wrote: post #150

The problem with redux is that it's a simple, extremely powerful tool for creating a CQRS architecture on the front end but very few people treat it that way. Instead they bolt on things like rtk and add yet another layer of abstraction over their project. In those cases it's almost always better to just use something small and simple like Zustand, which the article called out. For bigger projects, custom middleware…

Pretty sure you and I debated "vanilla Redux" vs RTK in a thread a couple years ago, but I'll link my most recent explanations of why RTK is the right way to use Redux today: - https://redux.js.org/introduction/why-rtk-is-redux-today - https://blog.isquaredsoftware.com/2022/06/presentations-mode... Also, note that RTK has a new "listener" middleware that simplifies the process of "run this code when some action is di…

I get it, you're _really_ invested in RTK but man, I just find it to be the right answer to the wrong question.

Since we last talked I have worked on projects where rtk was used because the devs didn't really grok redux and so far that's the best use case I've run across. That said, now when I run across situations like that I tend to guide clients to simpler state management solutions instead of piling on another layer of abstraction.

Re: The new wave of React state management

#164

Post by acemarke »

ggregoire wrote: post #162
acemarke wrote: post #156

Earlier quoted context omitted.

Yeah, both the React Query and Redux maintainers agree that you shouldn't be writing data fetching and caching logic yourself. That's why we recently added a new "RTK Query" data fetching and caching API to Redux Toolkit, so that if you're using Redux it handles that work for you: - https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... - https://redux-toolkit.js.org/rtk-query/overview and if you're just usi…

Yes we chose Redux 6 years ago for data fetching and caching when there wasn't as many alternatives as today!

Hah, yeah, the ecosystem landscape has definitely changed over the last few years :)

Re: The new wave of React state management

#166

Post by ChefboyOG »

aaaaaaaaaaab wrote: post #122
jitl wrote: post #24

Earlier quoted context omitted.

This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input de…

Bullshit. In 1995 people were creating desktop UIs order of magnitude more complex than today's anemic webapps, without any of the braindamage-inducing stuff that's happening in web UI development.

I was legitimately curious about this--my memory of Windows 95 is not this nice--so I looked at Wikipedia's list of software released in 1995:

https://en.m.wikipedia.org/wiki/Category:1995_software

What software specifically do you recall being "an order of magnitude more complex" than today's popular web apps?

Re: The new wave of React state management

#167

Post by shroompasta »

Zustand is a lot more popular than the comments or the article implies. I see it quite heavily used amongst Netflix engineers.

That being said, prop drilling was made more of an issue than it really is, especially considering the boilerplate needed for state management libraries like Redux.

But if there does need to be a global store, I usually reach for zustand as the API is probably the easiest out of the ones mentioned.

Re: The new wave of React state management

#168

Post by have_faith »

windowshopping wrote: post #120

I'd like to share my approach to React state management, because after a decent amount of industry experience I've stumbled onto a solution I find to be very excellent. Firstly, I use the open source library Pullstate[1], which I find to be as effective as any alternative but _far, far_ simpler to understand and use. All my components are functional components. For any state that _only_ that component needs, of cours…

You might like the atomic state management libraries mentioned in the article, they simplify things to another level because they sort of remove the concept of a store entirely. For example in Recoil I would do this:

    export const isSidebarOpenAtom = atom({key: 'isSidebarOpen', default: false});
And in the component: (it mimics useState)

    const [isSidebarOpen, setIsSidebarOpen] = useRecoilState(isSidebarOpenAtom);
and later...

    setIsSidebarOpen(true)
Recoil will then re-render any component that relies on isSidebarOpen.

The only real boilerplate is having to specify keys for each atom, which I find a small price to pay for such simple global state.

Re: The new wave of React state management

#169

Post by likortera »

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…

I've only used SWR. How does it compare? I

Re: The new wave of React state management

#170

Post by todd3834 »

I’ve been using redux ever since it came out and a home rolled flux architecture before that. I gotta say I’ve been using zustand lately and it feels so effortless compared to other solutions. I couldn’t imagine going back to redux. Although redux slices feel a little bit closer.
Post reply on HN