The new wave of React state management • Hacker News Board

Re: The new wave of React state management

#171

Post by krall12 » Sat, Jul 02, 2022, 9:27 PM UTC

likortera wrote: post #169

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

SWR does basically the same core thing (query, cache and mutation help) with less features.

Re: The new wave of React state management

#172

Post by ashishb » Sat, Jul 02, 2022, 9:37 PM UTC

Afaik, Vue ships with batteries included.

Re: The new wave of React state management

#173

Post by lloydatkinson » Sat, Jul 02, 2022, 9:49 PM UTC

glenjamin wrote: post #132

I find it very disappointing that this article does not attempt to draw a distinction between state management for complex local states (imagine an image editor), or state management for fetching and updating data via APIs I think the shape of solution needed for these two problems are quite different.

Same here. Local state and server state are not always the same. I see a lot of people saying how replacing redux with react query worked well and that’s great but there’s definitely times when you have a lot of state in a client side heavy SPA. The distinction should really be highlighted more.

Re: The new wave of React state management

#174

Post by meling » Sat, Jul 02, 2022, 9:52 PM UTC

I’ve not seen overmindjs mentioned on hacker news. We use it in our React app and my students who wrote the code liked it a lot… maybe others have advanced enough by now to be on par with or better than overmindjs.

https://overmindjs.org/

Re: The new wave of React state management

#175

Post by gloryjulio » Sat, Jul 02, 2022, 10:05 PM UTC

glenjamin wrote: post #132

I find it very disappointing that this article does not attempt to draw a distinction between state management for complex local states (imagine an image editor), or state management for fetching and updating data via APIs I think the shape of solution needed for these two problems are quite different.

Exactly. I think people who complains about complexity of some of the tools, just have not worked on the complex webapp(not the webpage) before. Unfortunately these 2 always get conflated.

Re: The new wave of React state management

#176

Post by aaaaaaaaaaab » Sat, Jul 02, 2022, 10:13 PM UTC

ChefboyOG wrote: post #166

aaaaaaaaaaab wrote: post #122

Earlier quoted context omitted.

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?

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

Re: The new wave of React state management

#177

Post by russellpekala » Sat, Jul 02, 2022, 10:30 PM UTC

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.

Re: The new wave of React state management

#178

Post by robocat » Sat, Jul 02, 2022, 10:32 PM UTC

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

JavaScipt on the browser is cursed[1].

1. There is no standard GUI library, as per article. A GUI can be as arbitrarily complex as you wish, and every different frontend system is a unique GUI system deployed in JavaScript, usually using HTML for the view drawing primitives* and events for input. The complexities of GUI library design bubble up to developers who are implementing their own tweaks or combinations of a GUI library, usually with a huge amount of “needless” variation. Application developers should ideally never have to be making choices about internals of a GUI system, yet the core of most articles comparing frontend frameworks is discussing GUI internals.

2. There is no golden standard for tooling. Everyone has their pet variations on how to deploy to JavaScript, CSS, and HTML.

3. Back end choice. Huge variation.

As a developer we get APIs on the edges, but we make our own spaghetti to join everything how we wish because there is not one or two standard library/framework choices, and we have the power to do what we will. I developed my own 100% custom component framework because I could write one that suited us far better than what was available at the time (OSS or commercial). Browser variation used to be a huge driver for complexity, but is far less so now.

* drawing primitives can also be Canvas or SVG or WebGL e.g. https://news.ycombinator.com/item?id=27131659 is a good comment.

[1] https://www.google.co.nz/search?q=lisp+curse

Re: The new wave of React state management

#179

Post by 42e6e8c8-f7b8-4 » Sat, Jul 02, 2022, 10:35 PM UTC

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 believe the worst part is redux. React is mostly reasonable. Redux is massive boilerplate.

Re: The new wave of React state management

#180

Post by chrisco255 » Sat, Jul 02, 2022, 10:46 PM UTC

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.