The new wave of React state management • Hacker News Board

Re: The new wave of React state management

#61

Post by acemarke » Sat, Jul 02, 2022, 4:50 PM UTC

nine_k wrote: post #56

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.

Fun fact: one of the XState devs did a proof-of-concept showing how to use XState state machines as Redux reducers and integrate the side effects handling as a middleware:

https://github.com/mattpocock/redux-xstate-poc

We'd like to work together to turn that into a more official integration sometime soon.

Re: The new wave of React state management

#62

Post by doitLP » Sat, Jul 02, 2022, 4:51 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".

Link: https://grugbrain.dev/

It is universally worth your time to read it if you haven’t :)

Re: The new wave of React state management

#63

Post by xeromal » Sat, Jul 02, 2022, 4:52 PM UTC

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 once that cache is sufficiently complex, it's just a state store like redux.

Re: The new wave of React state management

#64

Post by ramesh31 » Sat, Jul 02, 2022, 4:53 PM UTC

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.

Once you see the light of state machine based UI's, it's immediately obvious and you never want to go back. The problem comes in convincing others to deal with the boilerplate. It's worth it, but it never really sinks in until you use it.

Re: The new wave of React state management

#65

Post by kizer » Sat, Jul 02, 2022, 4:54 PM UTC

cercatrova wrote: post #53

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.

I don't know why but front-end terminology always makes me cringe. I know it's useful jargon. I don't know why I have a visceral distaste for them. Maybe because it feels like taking a small, simple thing and making it seem like it's something more.

But you're right. I haven't done much front-end at large scales. Only at one employer for a short while.

Re: The new wave of React state management

#66

Post by aarpmcgee » Sat, Jul 02, 2022, 4:55 PM UTC

wereHamster wrote: post #45

Weird that XState was not mentioned.

Agree. I am working on a side-project and using XState for local state management, and Jotai (with Immer) to send that state to various components in my app. It is working really well and mitigating unnecessary rerenders.

More moving parts than I might like, but they play together nicely and I haven't hit a single wall yet.

Re: The new wave of React state management

#67

Post by phaedryx » Sat, Jul 02, 2022, 4:55 PM UTC

m_ke wrote: post #2

Mobx solved all of the state problems properly a long time ago.

That's actually what converted me to Vue. I did all of the Redux stuff, but then found Mobx and enjoyed that so much more. A friend of my told me "if you like React + Mobx you'd probably like Vue" (I think he was quoting from the Vue website). He was right.

Re: The new wave of React state management

#68

Post by ramesh31 » Sat, Jul 02, 2022, 4:55 PM UTC

I'm just tired of the redundant reinvention of new "terms" for literally everything in JS. I don't want to know what an "atom" or a "proxy" or a "thunk" is. These are meaningless abstractions that simplify down to a store and a callback. Stop inventing terms to make yourself feel smart.

Re: The new wave of React state management

#69

Post by mllllv » Sat, Jul 02, 2022, 4:55 PM UTC

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…

I disagree, I think UI programming is inherently quite simple. Especially with a paradigm like immediate-mode GUIs in my opinion. I believe the complexity comes from the fact that the DOM is a poor API for creating user interfaces, which ultimately inspired developers to create frameworks that work in a more “immediate-mode” style way.

Re: The new wave of React state management

#70

Post by ramesh31 » Sat, Jul 02, 2022, 4:58 PM UTC

UmbertoNoEco wrote: post #18

Or you just manage state in the server. With https://inertiajs.com/ you can even afford to not to declare an API and still manage the state back there.

>Or you just manage state in the server. With https://inertiajs.com/ you can even afford to not to declare an API and still manage the state back there.

Then we can party like it's 1999!