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

51–60 of 310 posts

Re: The new wave of React state management

#51

Post by rglover »

doodlesdev wrote: post #27

I'm pretty sad this is the point we are at with React frontend development, the library is becoming much larger than it's original scope and it's getting bloated while not solving the essential problems that happen. In my opinion the best solution we have right now for frontend JS development is to not use JS or JSX at all and instead use a DSL such as Svelte, this way the compiler abstracts all complication and ther…

This is why I'm building Joystick: https://github.com/cheatcode/joystick.

It riffs on the old, simple APIs of React but uses pure HTML, CSS, and JavaScript w/o any trickery (I'm also hardcore about not changing the component API so WYSIWYG).

The bonus is that it's a part of a full-stack framework (the UI framework has a Node.js counterpart), so wiring up a full app is near-effortless.

Re: The new wave of React state management

#52

Post by aidos »

acemarke wrote: post #37
geraldwhen wrote: post #33

Earlier quoted context omitted.

You need redux saga because api interactions can be complex. I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display. But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy. Oh, an…

For the record, we actually have recommended _against_ using sagas in most cases for a long time now, and especially for data fetching. Today, our recommendations are: - Data fetching: default to using RTK Query, fall back to thunks if needed - Responding to actions or state changes: use the new RTK "listener" middleware as the main approach See my recent talk "The Evolution of Redux Async Logic" for details: - https…

Oh my. What is this ecosystem where the maintainers are downvoted for explaining the current recommendations for those using their library?

Re: The new wave of React state management

#53

Post by cercatrova »

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've often found those that complain about these buzzwords are the people who do not actually do any frontend engineering. There are buzzwords in every language and every library. It's not an indictment of complexity (which exists outside of any one language or library), it is simply the terms of the trade of that particular technology.

Re: The new wave of React state management

#54

Post by nwh5jg56df »

jitl wrote: post #24
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".

This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input de…

We went to the moon some +50 years ago. We ought to have solved "UI programming" already, no?

Something is not working

Re: The new wave of React state management

#55

Post by sph »

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

It makes me smile that elsewhere in this thread there's people saying "I've been using and state management is now super easy." when you know in two months people will be saying that library is over-engineered and someone will suggest to try the new panacea that will solve all of your problems, for real this time.

Such is the hype cycle of frontend development.

Re: The new wave of React state management

#56

Post by nine_k »

johtso wrote: post #46

For me using xstate was a game changer. Pulling logic out into a state machine gives you so much clarity over your application logic. Also nice to have your business logic defined with something that is framework agnostic.

Yes! An explicit state machine is my desire for the UI development since the Delphi days of 1990s. It makes things so much more observable and sane.

Redux nudges you to build that state machine by hand, in the form of the reducers folder, around the centralized state. While elucidating, it's still a lot of boilerplate (which you can sort of factor out), and it's still not one clearly laid out entity.

Re: The new wave of React state management

#57

Post by rebelos »

melony wrote: 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.

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.

Re: The new wave of React state management

#58

Post by acemarke »

kitten_mittens_ wrote: post #44
etimberg wrote: post #16

Earlier quoted context omitted.

I think it's because redux is quite painful to use with very modern apps. Most of the time you need something like `redux-saga` or `redux-thunk` to deal with async side effects. I'm not sure which is the most popular today, but sagas are based on generators and trying to use those with typescript is very very painful and the underlying issue [1] is marked as a design limitation in TS itself. In addition, if you want…

arcanis has a PR to patch up the issue that's sat for a year plus now. https://github.com/microsoft/TypeScript/issues/43632 > In addition, if you want to have your app load as smaller chunks rather than a single large bundle, you need to be careful to ensure that things work even all the backing reducers aren't yet loaded. In the decade old application we use redux saga in at work, a large portion of our 7MB minified…

We have docs on code splitting reducers and other Redux logic here:

- https://redux.js.org/usage/code-splitting

There have been some different community packages for helping with that process, but some of them seem to have become outdated (only worked with React-Redux v5, etc). I did see a new one at https://github.com/fostyfost/redux-eggs that seemed like it had potential, but I haven't had a chance to try any of them myself.

I also once saw someone play around with the idea of using React's still-not-technically-final Suspense support to help ensure that a lazy-loaded component that relies on a code-split reducer doesn't actually get rendered until that reducer's state is available. Don't have the link handy atm, but if someone wants it ping me and I can go figure out where that was described.

Also, the new RTK "listener" middleware was specifically designed to replace almost all saga usages, and you can dynamically add more listeners at runtime via dispatch an `addListener()` action:

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

- https://blog.isquaredsoftware.com/2022/05/presentations-evol...

Re: The new wave of React state management

#59

Post by xeromal »

jeroenhd wrote: post #7

I've used Redux but I've never heard of any of these alternatives. I have no doubt they're popular, but what is it about frontend that makes everyone reinvent the wheel every five years? Everything from the tooling to the tiny details somehow expires and gets recreated in a similar-but-not-similar-enough way that keeps the ecosystem in a constant state of flux. Is it the lack of platform API support? Is it the commun…

"What's wrong with frontend?"

This is the age-old question. You're using Redux now, but I'm sure some JQuery/Angular/Knockout/etc dev said the same thing about what you're using back then.

The front-end is crazy and I don't think there's an obvious answer of why it's such a developmental disaster. It's easy to say it's run by script kiddies or the barrier to entry is too easy, but there are a lot of smart devs working on the top libraries. The culture just ended up this way. Whatever is driving it probably will never stop though. Enjoy the ride. lol

Re: The new wave of React state management

#60

Post by kaoD »

petilon wrote: post #28
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…

> You can’t represent that state on the server without making the UI unusably slow. And that's why you use a client-side cache.

And that's why you need state management. Cache is state.
Post reply on HN