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

241–250 of 310 posts

Re: The new wave of React state management

#241

Post by azemetre »

wruza wrote: post #204
tadfisher wrote: post #94

Earlier quoted context omitted.

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?

This talk from Rich Harris should answer most of your Qs:

Rethinking reactivity

https://www.youtube.com/watch?v=AdNJ3fydeao

He goes over the history of spreadsheets, reactive programming, and dunks on react.

Re: The new wave of React state management

#242

Post by ksbrooksjr »

BigJono wrote: post #217
ksbrooksjr wrote: post #114

Earlier quoted context omitted.

Most state management libraries help you deal with the problem of sharing state between multiple components. In modern React, most components are just functions, so this boils down to passing state through deep call stacks. If you have a component A, which renders component B, which in turn renders component C, without a state management library you'd have to pass state from A to B to C (this is often called prop dri…

React already has a mechanism for this (Context). It's not the primary reason to use a state management library. Any discussion that doesn't revolve around a difference between the two is akin to suggesting re-implementing a standard library call for literally no reason.

The commenter I was replying to wasn't inquiring about why people choose third-party state management libraries in lieu of the standard context api. In fact, he's not even a web developer.

He seemed to be wondering why you need a state management solution in the first place. If he had asked why people prefer Zustand, or Redux, or Recoil over React's built in context api then I would have replied accordingly.

I was largely expounding upon the linked article's first list item under the heading "The problems global state management libraries need to solve". The first item in that list begins with:

> Ability to read stored state from anywhere in the component tree. This is the most basic function of a state management library. It allows developers to persist their state in memory, and avoid the issues prop drilling has at scale.

I would argue that the primary function of state management libraries is still sharing state between components. Third-party libraries might expose a more performant, simpler, or more intuitive api, but that's still their primary purpose. Analogously, if a non-compiler developer asked why programming languages need memory management, you wouldn't delve into the differences between reference counting and tracing garbage collection.

Re: The new wave of React state management

#243

Post by valand »

LAC-Tech wrote: post #184

I think the obsession the react space has with "state management" is a by-product of how incredibly convoluted reacts rendering is. The other reason is a lack of exposure to how other technologies for GUIs have handled state for decades. Maybe look outside the react bubble and see how many of these "issues" just disappear when you stop acting like react is some fundamental particle of the web.

Almost true. As someone who have been working on a complex desktop app for 4 years now.

I found that state management solutions are always incomplete for the problems we have in our team.

When you say "stop acting like react", it is actually true that some mechanism needs to escape from React's render loop while retaining its tree-like structure. New members to the team will have to be introduced to the idea that an actor (object that acts on data) does not need to be the same entity as the React component itself. We end up taking a lot of concepts from other domains such as game engine, Rust's ownership/borrowing

What we ultimately need are that's not fulfilled by many state management libraries out there:

- Instead of global vs local, we need management of scope, referability, and intuitive dependency injection. - Instead of state, we need management of actors. - Management of lifetime, ownership, and borrowing (concept taken from Rust) - A differentiator between actor, function, and data (which entity should or should not do stuffs) - Two-way communication channel - A consistent code semantic that makes sense to describe it all because TypeScript/JavaScript does not cut it.

Re: The new wave of React state management

#244

Post by bcherny »

dham wrote: post #215
bcherny wrote: post #22

Earlier quoted context omitted.

Your causation is reversed. People demanded more interactive web apps, which led to more stateful UI, which led to React. In the case of Facebook, the motivating app was Ads Manager — an enormous, highly interactive single page app for advertisers. You couldn’t build something like it with HTML + server endpoints; in the pre-web days, apps with this kind of complexity would be desktop apps. Google Docs, Google Sheets…

> People demanded more interactive web apps, which led to more stateful UI, which led to React. Except they didn't. 99% of web developers work on crud apps, not Figma. The users never really cared. You can achieve "good enough" results waiting for server. I still see over fetching from server instead of updating caches in most frontend apps anyway. Things like a button optimistically updating, just show a spinner and…

Both things are true: people wanted more interactive apps; at the same time, most engineers don’t work on those kinds of apps.

A frequent analogy: React raises the ceiling for the kinds of experiences you can build in a browser.

But not every app hits that ceiling. If CRUD works for you, do that. The simpler the better.

Re: The new wave of React state management

#245

Post by [deleted] »

Yhippa wrote: post #116
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…

Question for you since you seem knowledgeable about React state management. When I did a lot of back-end programming in Java we frequently coded to interfaces where we could swap out back-end implementations for ORM for example if needed. There's an ongoing joke where nobody actually did that. Is there something like that in React? My understanding is that there's a lot of coming and going of state management framewo…

[deleted]

Re: The new wave of React state management

#246

Post by nsonha »

It's annoying that they now reinvent yet another old thing (proxy based dependency tracking). This seems to be a pattern in the React community. These libraries are great but they offer nothing new comparing to mobx, which started even before redux became ridiculously popular.

Re: The new wave of React state management

#247

Post by b0ner_t0ner »

wokwokwok wrote: post #222
ezekiel11 wrote: post #151

I ditched React/Redux for Vue 3 & Pinia and my god, what a world of a difference. Everything is intuitive and I am not googling days to fix tooling issues, or having to do it the React/Redux way which was honestly overly engineered and non-productive. Frontend shouldn't be complicated and we've been lied to, you are not Facebook, you don't have billions to throw at engineering, you must pick the path of list resistan…

I'm pretty surprised. I recently did the same, and hand's down, the vue ecosystem is weak. Vue is difficult to work with (unable to render content without a functional component wrapper, poor support for style libraries like tailwind), and the state management ecosystem is fractured between vuex and pinia. Worse, much of the help online is for old versions (vue2). Storybook 'out of the box' is broken and doesn't work…

> and the state management ecosystem is fractured between vuex and pinia

What do you mean fractured? They official recommend Pinia: https://vuejs.org/guide/scaling-up/state-management.html#pin...

> Storybook 'out of the box' is broken and doesn't work at all (unable to resolve '@/...' imports). It's been painful.

So you're blaming Vue because of bad experience with storybook?

Re: The new wave of React state management

#248

Post by viraptor »

nyanpasu64 wrote: post #226
LAC-Tech wrote: post #184

I think the obsession the react space has with "state management" is a by-product of how incredibly convoluted reacts rendering is. The other reason is a lack of exposure to how other technologies for GUIs have handled state for decades. Maybe look outside the react bubble and see how many of these "issues" just disappear when you stop acting like react is some fundamental particle of the web.

Frankly I feel state management is a difficult task on desktop apps as well, to the point that tracking spaghetti-shaped causation and control flow is beyond my mental abilities. Qt itself as well as many apps are rife with redundantly calculating state or redrawing GUIs when changing the same value multiple times, or changing two values which both affect an outcome (my StateTransaction pattern mostly alleviates this…

While I don't deal with the ui too much (and hate the area / complexity), the best system I've seen so far is .net's WPF with MVVM pattern. You wire up the ui elements to models and things just work. Data dependencies are explicit, useless redraws are not happening if you schedule the changes on the right thread, the whole system can raise a coherent "binding error" rather than explode. It's definitely a solution I hate the least.

Re: The new wave of React state management

#249

Post by proxyon »

kizer wrote: post #42

"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.

I understand all of these words and they are important to my daily workflow because I do serious frontend development. I'm not trying to offend you but your comment simply indicates that you do no serious frontend development.

Re: The new wave of React state management

#250

Post by proxyon »

shroompasta wrote: post #167

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 ment…

We use Valtio but Zustand was a close second runner up
Post reply on HN