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

181–190 of 310 posts

Re: The new wave of React state management

#181

Post by chrisco255 »

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?

As we know from computer science, there are two difficult problems: naming things and cache invalidation. State management is inherently difficult in web apps (I think it's inherently difficult for any complex application). They are effectively distributed systems with local caches and remote server data that need to be synced correctly in order to manage a user application at scale. That all has to align with how the presentation logic is built. It has to deal with the constraints of the web platform, etc.

Re: The new wave of React state management

#182

Post by MentallyRetired »

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…

Bingo. React is great for insane amounts of fine grained control.

But I don't want that. I want to build interfaces and not "manually shift" my local state management.

Re: The new wave of React state management

#183

Post by frosted-flakes »

pcthrowaway wrote: post #96
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.

> Now you have all the problems from the article since you need to update all the components everywhere on screen that share state. If anyone can field a question about react-query here, this seems like one of the exact problems I thought it solved when I started using it. I do enjoy using it, but requesting the same data with the same key+queryFn from multiple, unrelated components still generates regular requests a…

React-Query is very aggressive about refreshing the cache by default, including whenever the browser receives focus, on a set schedule, and automatically retrying failed queries multiple times, these can all be disabled. If any queries use the same key they should share data, but I haven't experimented with it enough to learn all its intricacies.

Re: The new wave of React state management

#184

Post by LAC-Tech »

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.

Re: The new wave of React state management

#186

Post by chrisco255 »

aaaaaaaaaaab wrote: post #176
ChefboyOG wrote: post #166

Earlier quoted context omitted.

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?

Just from the top of my mind: Excel, Word, Photoshop, Windows Commander (called Total Commander today), SolidWorks, AutoCAD, Borland Delphi.

Excel is quite complex, but the Excel of 2022 is far more complex than the Excel of 1995, and part of it exists on the web itself, so Excel '22 would be an invalidation of your argument that '95 apps were more complex (as well as other modern versions of the other apps).

One major difference in 1995 applications is that almost none of them were collaborative or synced with a remote server. They were all isolated applications that worked entirely in a local context. They could be programmed to a single target platform on perhaps one to three screen resolutions (640x480, 800x600 and 1024x768). They could all work under the assumption that one style of input was being used (mouse and/or keyboard). They all could use simple built-in dropdown context menus. They could all render to a canvas context graphics with much of the heavy lifting assumed by the operating system itself.

Re: The new wave of React state management

#187

Post by yulaow »

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.

Think of the user having a number of games running in parallel equal to the usual number of tabs you have open in the browsers.

Re: The new wave of React state management

#188

Post by melony »

purplerabbit wrote: post #103
rebelos wrote: post #57

Earlier quoted context omitted.

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.

I'm sorry people are downvoting, because you are correct. SSR (by which I mean Next.js) is the most over-invested in JS tech of all time. It introduces a bunch of crummy DX which never pays for itself from a business standpoint. SSR is only potentially useful for landing pages. In which case you should be using Wordpress or something like Wordpress so you aren't wasting dev resources on something a marketing team sho…

And how exactly do you plan to avoid the flash of white without SSar?

Re: The new wave of React state management

#189

Post by acemarke »

chrisco255 wrote: post #180
bayesian_horse wrote: post #157

I didn't get the memo apparently. I still think Redux+Thunks+Selectors+Sagas is great and that combination solves all my problems. Boilerplate isn't negligible but relatively tame. There's a straightforward way how to model state, and I don't have to put too much logic (especially async) into components. But that's just me...

Yeah I've always thought the complaints about boilerplate were misguided. Whatever the cost in boilerplate implementation was more than made up for by having predictable, deterministic UI output. That being said, I think hooks did open up the state management design space quite a bit and classic redux style state management doesn't quite line up with it. Still totally valid as an architecture, though, in my opinion.

Eh, as maintainer, I'd say the complaints about "boilerplate" were generally pretty accurate :)

As I've talked about in a couple posts and presentations [0] [1], there's a distinction between "inherent" and "incidental" complexity. Dispatching actions and using reducers is "inherent" - it's part of Redux, and you can't remove that because then it's not Redux. But things like writing `const ADD_TODO = "ADD_TODO"`, object spreads, etc, aren't _necessary_ for using Redux - they're inherent complexity.

Which is why we wrote Redux Toolkit to fix all that incidental complexity :)

Redux still won't ever be as few lines of code as various other libs, but writing Redux code today is much simpler than it was previously... and yes, the _benefits_ of Redux (predictable code, debugging, separation of state updates, middleware) are still entirely valuable.

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

[1] https://blog.isquaredsoftware.com/2019/10/redux-toolkit-1.0/

Re: The new wave of React state management

#190

Post by Kiro »

yulaow wrote: post #187
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.

Think of the user having a number of games running in parallel equal to the usual number of tabs you have open in the browsers.

(Sorry, I edited my comment and removed the game reference and optimization question before I saw your comment.)

I mean, sure but the DOM is not even a factor compared to the actual WebGL rendering going on. The DOM is only used for UI, menus and things like that. So the bottleneck would still not be React or how I handle state.

Post reply on HN