The new wave of React state management • Hacker News Board

Re: The new wave of React state management

#91

Post by mechanicum » Sat, Jul 02, 2022, 5:47 PM UTC

acemarke wrote: post #74

ramesh31 wrote: post #68

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.

FWIW, the term "thunk" is a long-standing CS term that long predates Redux [0] [1] [2]. In fact, my first job back in 2008 involved a C++-based emulator/VM framework, and the devs used "thunk" to refer to jumping from the original program binary out to altered/replacement code written as C++ to add additional behavior or replace functionality. "Proxy" is also a long-standing term as well that describes wrapping or re…

And “atom” comes from Clojure’s atomically updatable state. [0] [1]

[0] https://clojure.org/reference/atoms

[1] https://news.ycombinator.com/item?id=23183385

Re: The new wave of React state management

#92

Post by sebmellen » Sat, Jul 02, 2022, 5:47 PM UTC

For anyone who has not had the pleasure of working with these simpler “atom-based” state management libraries, I would implore you to try Jotai (https://jotai.org/), which is mentioned in the article.

Jotai’s atomic model and ease of use has made writing complex React applications far more joyful for me.

Re: The new wave of React state management

#93

Post by Waterluvian » Sat, Jul 02, 2022, 5:49 PM UTC

cercatrova wrote: post #38

Waterluvian wrote: post #6

I used Redux and loved it until I moved to typescript. Then there was a terrible amount of boilerplate and magic. So I wrote my own 75 line alternative that does a bare minimum. It’s basically just a useContext wrapper. And I haven’t looked back since. This is for pure client side stuff, of course.

Context and Redux are somewhat different tools and context doesn't necessarily solve the same problems as Redux. This article by the maintainer of Redux (acemarke) goes over why (looks like he replied to you as well) [0]. Have you tried Redux Toolkit as well? It cleans up a lot of the complexity of Redux and works well with TypeScript [1]. [0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff... [1] https:…

Basically I’m not saying redux is bad. Just that after years of using it for production software I concluded it’s still overkill for my needs.

IIRC Redux is also just an abstraction on top of Context. Fundamentally it gives you pseudo-global access to application state by being able to interact with it anywhere in the component tree below the context manager.

Re: The new wave of React state management

#94

Post by tadfisher » Sat, Jul 02, 2022, 5:52 PM UTC

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?

Reactive programming provides the capability to react to changes in state. You still need to hold that state somewhere, mutate the state from your reactive code, and control the lifetime/scope of that state. Managing state becomes more of a concern with reactive programming, but it also becomes very explicit; this is something that traditional MVC approaches try to hide, to the detriment of anyone trying to understand the data path of your application.

Re: The new wave of React state management

#95

Post by acemarke » Sat, Jul 02, 2022, 5:52 PM UTC

geraldwhen wrote: post #87

acemarke wrote: post #37

Earlier quoted context omitted.

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…

We specifically moved off thunks because the capricious whims of changing network calls with logic to support it is so much easier in redux saga. Stuff just works. You can handle every edge case. And now there are multiple deployed production apps with real users, so it’s almost certainly never going to be replaced. The cost would be enormous.

Yeah, I'm not questioning whether you _can_ do things with sagas, and there's definitely cases where their capabilities are valuable.

But as I put it in my "Evolution" talk: "Sagas are like a chainsaw. Really powerful, and really dangerous. If you actually _need_ that power, great! But most of the time you don't actually _need_ to use a chainsaw on a daily basis."

As the sibling comment said, a lot of times sagas really do end up as spaghetti code, largely because they are so event-driven, and with all the use of generator functions that can make debugging hard. (Ironically, the original Flux Architecture was created to _avoid_ the problems of Backbone-style event triggers causing events to ricochet around the app without a way to understand how things would update in response, and sagas can end up recreating that problem with Redux apps.)

Re: The new wave of React state management

#96

Post by pcthrowaway » Sat, Jul 02, 2022, 5:58 PM UTC

wilde wrote: post #12

petilon wrote: post #4

The "state management problem" appears to be an invention of React. This didn't use to be a problem with MVC. The state lives on the server. When state changes it should be persisted on the server immediately (in case the user unexpectedly closes the browser). On the client all you need is a cache. With MVC, each page is more or less independent. Each page gets the data it needs from the server (through a client-side…

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 at the configured interval (even if I'd want/expect those components to share the response and only make that request at whatever rate satisfies the shortest configured interval)

Am I missing something in my configuration here?

Re: The new wave of React state management

#97

Post by acemarke » Sat, Jul 02, 2022, 6:00 PM UTC

Waterluvian wrote: post #90

acemarke wrote: post #35

Earlier quoted context omitted.

Hi, I'm a Redux maintainer. FWIW, we specifically designed our official Redux Toolkit package to not only eliminate the general concerns about Redux "boilerplate" [0] [1], but also work great with TS. With our recommended RTK+TS usage patterns, a typical "slice reducer" file only needs to define a type for the reducer's state, and then define a case reducer as `(state, action: PayloadAction `) [2], and that's it. We'…

Hooks made react and redux far less ridiculous. Class based react and redux wss maddening. I’ll poke again but last time I tried I couldn’t avoid Typesafe Actions library.

Yeah, _please_ don't use `typesafe-actions` :)

It may have had some value before RTK came out, but a lot of the opinions and approaches shown in its docs lead you to write _wayyyy_ too much code. For example, we specifically recommend _against_ writing TS unions for action object types [0].

RTK completely obsoletes `typesafe-actions`, and the TS usage patterns that we teach today should result in a pretty minimal set of types that you need to write in your own code.

For a small example see the RTK+TS template for Create-React-App [1]. If you want to see what a real app codebase can look like, the client app for my day job at Replay.io is OSS [2]. It's admittedly a somewhat messy codebase due to its long evolution and legacy (started as the FF DevTools codebase, copy-pasted, and we've been slowly migrating to RTK+TS and modernizing it), but files like [3] show how I would write a real slice reducer with RTK+TS.

[0] https://redux.js.org/usage/usage-with-typescript#avoid-actio...

[1] https://github.com/reduxjs/cra-template-redux-typescript

[2] https://github.com/replayio/devtools

[3] https://github.com/replayio/devtools/blob/454804188d33900a26...

Re: The new wave of React state management

#98

Post by doodlesdev » Sat, Jul 02, 2022, 6:01 PM UTC

sachinraja wrote: post #76

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…

How is React not solving essential problems? Suspense solves a pretty essential issue. Also Svelte can quickly increase in bundle size and if you have enough components, it can become bigger than the equivalent in other frameworks: https://github.com/yyx990803/vue-svelte-size-analysis .

The first version of React was released on 2013, it took almost 10 years for Suspense to exist (we _just_ got it now with React 18), that's what I'm talking about. Even functional components and hooks took a lot of time from them get and implement the idea after they tried to use ES classes and made everything much harder to manage. Context also isn't perfect, I like it but the redraw performance is not amazing and doesn't scale at all to bigger applications.

> https://github.com/yyx990803/vue-svelte-size-analysis

This is an interesting comparison I haven't seen before, I wonder if it's true for a complete application using some lib for state management, routing, etc. and if this isn't just a kind of cherry picked example. Thanks for showing this though.

Re: The new wave of React state management

#99

Post by rochak » Sat, Jul 02, 2022, 6:02 PM UTC

Has React become too big for people to not consider other alternatives? I used to be a big React advocate but realised that it is getting too bloated with every new release. Have been looking into Svelte and it is turning out to be a breath of fresh air compared to whatever React is culminating to be.

Re: The new wave of React state management

#100

Post by sakerbos » Sat, Jul 02, 2022, 6:03 PM UTC

I've advocated for Redux in many commercial projects because I knew that it worked well at scale. There was occasional pushback due to the large amount of boilerplate code involved (actions, reducers, sagas, models/interfaces if using Typescript) but the team mostly settled on Redux because it was the best supported and most widely used state management framework at the time. IMO the larger pool of devs that understand a framework, the better a project's chances are of success mainly because the industry has a high turnover of developers and it's easier to find replacements to maintain the existing code.

That being said, I'm now a huge fan of react-query.