Live data from Hacker News

The new wave of React state management

frontendmastery.com

191–200 of 310 posts

Re: The new wave of React state management

#191
post #9

Most of these new client side state management libraries are incompatible with any form of SSR. If you see the documentation for Jotai/Zustand/Valtio, the solution is to avoid using with Next.js at all, or fall back to hacks using context+provider at which point the state manager becomes effectively redundant.

I use Zustand with Next.js. What is the issue? There are even officially maintained examples by Next:

https://github.com/vercel/next.js/tree/canary/examples/with-...

And Jotai: https://github.com/vercel/next.js/tree/canary/examples/with-...

Re: The new wave of React state management

#192

Earlier quoted context omitted.

Agreed! I'm surprised at the comprehensive work going into researching the history of state management in this article while completely missing MobX. What problem does MobX not already solve?

What problem does MobX not already solve? I’d say the two biggest hazards with the reactive/declarative style are cyclic dependencies in the data model and remembering history. Tools like MobX let you write quite elegant code in the right circumstances but they are less helpful if, for example, you have a complicated set of constraints and the effects of changing one value in your state can propagate in different dir…

For a project that was basically an after effect like application I needed a history, but also very fast updates, settled with mobx-state-tree which gave me a way to preserve history. Worked great for that application, no regrets.

So there are some solutions available if normal mobx is not enough.

Re: The new wave of React state management

#193

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…

Have you considered something like "selector based side effects"? https://github.com/mikew/redux-easy-mode#selector-based-side.... The difference is most side effects are based around when an action is dispatched, but I wanted to know when things _change_.

It's possible to do the same thing with a react component + useEffect, but I thought a pure-redux solution would better fit the spirit of Redux.

Re: The new wave of React state management

#194

Earlier quoted context omitted.

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

Sure, all the other settings work fine (refresh on focus, failure retry, etc.), I just would have hoped to limit the requests made when the same data is requested in many different places.

Re: The new wave of React state management

#195

Earlier quoted context omitted.

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…

Have you considered something like "selector based side effects"? https://github.com/mikew/redux-easy-mode#selector-based-side... . The difference is most side effects are based around when an action is dispatched, but I wanted to know when things _change_. It's possible to do the same thing with a react component + useEffect, but I thought a pure-redux solution would better fit the spirit of Redux.

Yes, you _can_ actually do that with the listener middleware! We specifically designed that to be possible.

When you add a listener entry, there are four options to specify how the middleware knows when to run that listener: 1) `type`: an action type string; 2) `actionCreator`: an RTK action creator function like `todoAdded`; 3) `matcher`: an `(action: AnyAction): action is MyAction => boolean` type guard; and 4) `predicate`: an `(action, currState, prevState) => boolean` function.

In all cases, the middleware loops over all entries every time an action is dispatched, and checks to see if any entry is interested based on those comparisons. For the first three, it's just "does this action type match".

_But_ the `predicate` callback receives `currState` and `prevState` as arguments. That means that you can write checks to see if "this state field has changed due to the action":

    return currState.counter.value !== prevState.counter.value
or if "this state field matches some condition, such as:

    return currState.counter.value >= 3
This is covered in the API docs:

https://redux-toolkit.js.org/api/createListenerMiddleware#st...

FWIW, skimming the repo you linked (which I assume is your package), I'm pretty sure RTK either does the same things already (creating actions and reducers) or has equivalent solutions (listeners for "selector effects", `createAsyncThunk` for the "async middleware", RTK Query for data fetching).

Re: The new wave of React state management

#196

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.

React is at its core a state management library, not a UI framework. Of course people are obsessed with state management in that space.

Re: The new wave of React state management

#197

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.

This doesn’t work, the most sound comparison web developers can usually do is to jquery (speaking out of previous thread experiences, lots of them). I also see all this movement as digging more steps into the same pit they’re in, in hope that it would make a ladder out somehow. For two decades of building various business UIs on various platforms I’ve never felt that it was hard or error-prone at the level which could bother anyone to fix once and for all with some funny legs above head technique. But now it suddenly (well, gradually) became a thing everyone’s suffocating without.

Re: The new wave of React state management

#198

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?

Win 95 was a toy, NT was getting there. Apps were being ported quickly to NT4.

I do remember using Maya on Irix in '97 or so and it was already pretty amazing. It was built off earlier applications like power animimator, which was started in '88:

https://en.wikipedia.org/wiki/PowerAnimator

Maya had a customizable interface, and neat things like pie-menus, although not invented there.

Re: The new wave of React state management

#199

Earlier quoted context omitted.

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

We certainly had network programming in the 90s. It was just that apps didn't use it unless needed. SGI res was typically 1280x1024 and Wacom tablets were common in studio/professional settings.

Re: The new wave of React state management

#200
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.
Post reply on HN