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

201–210 of 310 posts

Re: The new wave of React state management

#201

Post by wonnage »

sakerbos wrote: post #100

I've advocated for Redux in many commercial projects because I knew that it worked well at scale. There was occasional pushback due to the large amount of boilerplate code involved (actions, reducers, sagas, models/interfaces if using Typescript) but the team mostly settled on Redux because it was the best supported and most widely used state management framework at the time. IMO the larger pool of devs that understa…

Redux is weird because it's only necessary at a certain scale, but it's the same scale where having a global shared object makes things really confusing. For example, suppose you're trying to deprecate a reducer; you need to find all consumers of the state it manages. But you can't, because there's no actual dependency between a reader of the store and the reducers. You're stuck wading through all the useSelector or connect() calls in the entire app; hopefully the reducer was managing a state branch with an easily-greppable name.

Re: The new wave of React state management

#202

Post by frosted-flakes »

memonkey wrote: post #125

Absolutely great article. One thing I always see missing is why front-end applications can't use sessionStorage or localStorage? Why is this generally frowned upon?

Most apps actually do use localStorage as a persist layer. But it's not a replacement for state libraries because it's just a place to store strings, and that's it. A state management library is so much more than a scratchpad.

Re: The new wave of React state management

#203

Post by wruza »

russellpekala wrote: post #177

I do find redux super helpful for undo/redo (as mentioned in the article) and have not found a similar library for another state management solution that can do quite what I need there.

You probably know it, but a friendly reminder: undo is just a callback doing a backwards operation, in an array named “undo stack”.

Re: The new wave of React state management

#204

Post by wruza »

tadfisher wrote: post #94
civilized wrote: post #88

Curious layman here (no web dev experience). I thought the main selling point of reactive programming was that it abstracted away the need to manage state. What problems, then, does a state management library solve in a reactive framework?

Reactive programming provides the capability to react to changes in state. You still need to hold that state somewhere, mutate the state from your reactive code, and control the lifetime/scope of that state. Managing state becomes more of a concern with reactive programming, but it also becomes very explicit; this is something that traditional MVC approaches try to hide, to the detriment of anyone trying to understan…

ELI5 why Excel can update all of the sheets from all the different data sources without overloading its user with “state management” thing and React can not?

Re: The new wave of React state management

#205

Post by buchanaf »

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…

RTKQ is terrific. Between things like that and MUI, the level of productivity you can achieve really is amazing.

Also, thanks for your work -- really, really appreciate it.

Re: The new wave of React state management

#206

Post by cercatrova »

dboreham wrote: post #137
kizer wrote: post #65

Earlier quoted context omitted.

I don't know why but front-end terminology always makes me cringe. I know it's useful jargon. I don't know why I have a visceral distaste for them. Maybe because it feels like taking a small, simple thing and making it seem like it's something more. But you're right. I haven't done much front-end at large scales. Only at one employer for a short while.

You're experiencing the cognitive dissonance from trying to understand unnecessary complexity.

As I mentioned, complexity abounds everywhere. It is hard to say what is unnecessary and what is not.

Re: The new wave of React state management

#207

Post by cercatrova »

acemarke wrote: post #106
Waterluvian wrote: post #93

Earlier quoted context omitted.

Basically I’m not saying redux is bad. Just that after years of using it for production software I concluded it’s still overkill for my needs. IIRC Redux is also just an abstraction on top of Context. Fundamentally it gives you pseudo-global access to application state by being able to interact with it anywhere in the component tree below the context manager.

> Redux is also just an abstraction on top of Context No, this is a very common but incorrect misunderstanding of how Redux works. It's true that React-Redux does use context internally... but only to pass down the Redux store instance, _not_ the current state value. Also, because Redux itself is separate from React, there's a lot of things you can do with it that are completely different than what Context does. _One…

I posted that same article above, I'm not sure if they didn't read it the first time that they'll read it the second time, lol

By the way, thanks for your hard work on Redux, appreciate it.

Re: The new wave of React state management

#208

Post by wruza »

ekidd wrote: post #131
petilon wrote: post #101

Earlier quoted context omitted.

Cache stays simple even for large applications. It never gets "sufficiently complex".

As the joke goes, there are two hard problems in software: 1. Naming things. 2. Cache invalidation. 3. Off-by-one errors. Caches are tricky beasts. First, you need to update them when the server-side state changes (for example, two people editing a single Google doc). Second, writing state changes to the server and waiting for confirmation is too slow for many kinds of interactions. In these cases, it's typical to op…

It’s all true, but you missed the part where react and/or redux are talking to the server to manage the cache. Because if they aren’t, it’s unclear why tf they are holding the mic.

Re: The new wave of React state management

#209

Post by tunesmith »

I still find the whole subject so frustrating. Being a backend developer that has since out of necessity had to transfer to being a frontend-architect for a team of confused React developers, I'm struck with how the momentum of frontend development quickly leads to very complex state machines. Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. But with frontend state machines, you've got things that feel like global state sitting all over the place.

If the logged-in user is this or that and/or the component state is this or that then do this unless that, and if this part of the component changes/re-renders to be that, then refigure the entire state all over again so this or that can be adjusted if necessary...

I mean, I get it, basically any GUI is going to have matters like this. And I get that the idea is to work really hard to limit the contract of each sub-component so that it can feel pure and only be dependent on a limited number of parameters/properties coming in. After all, on the backend it's also easy for a bad programmer to write a function/method that accepts forty parameters and has horrendously complex logic inside.

But in practice, something about the product cycle and the feature cycle of React just makes it so easy to turn into a huge snarl really fast. I feel like I'm battling against the tide. Maybe it's just something specific to our team and I need everyone to just freeze until we get some better practices in place.

Re: The new wave of React state management

#210

Post by Kiro »

wruza wrote: post #200
Kiro wrote: post #185

I just run force update on the root component 60 times a second and import the global state in every component that needs data from the store.

You may consider using some “schedule re-render everything at the next animation frame after an event” type of library instead.

I do have something like that but it mostly triggers every frame anyway due to so many things being updated.

With that said, do you know any libraries like that?

Post reply on HN