The new wave of React state management • Hacker News Board

Re: The new wave of React state management

#131

Post by ekidd » Sat, Jul 02, 2022, 7:32 PM UTC

petilon wrote: post #101

xeromal wrote: post #63

Earlier quoted context omitted.

And once that cache is sufficiently complex, it's just a state store like redux.

Cache stays simple even for large applications. It never gets "sufficiently complex".

As the joke goes, there are two hard problems in software:

1. Naming things.

2. Cache invalidation.

3. Off-by-one errors.

Caches are tricky beasts. First, you need to update them when the server-side state changes (for example, two people editing a single Google doc). Second, writing state changes to the server and waiting for confirmation is too slow for many kinds of interactions. In these cases, it's typical to optimistically write local changes to a local store, and then try to sync those changes with server asynchronously. But if synchronization fails, then the client needs to report that.

And finally, there's the problem of partially loaded state, where the rest is loaded asynchronously on demand. That should be simple, but without some kind of framework, it also tends to have lots of subtle state-machine and null-reference bugs.

So, no, cache does not always stay simple in large applications. (Unless the app is read only, and you're OK showing stale data.)

Re: The new wave of React state management

#132

Post by glenjamin » Sat, Jul 02, 2022, 7:32 PM UTC

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.

Re: The new wave of React state management

#133

Post by andrewljohnson » Sat, Jul 02, 2022, 7:33 PM UTC

DonHopkins wrote: post #127

>For example with local UI state, prop drilling both data and methods to update that data often becomes a probably relatively quickly as things grow. Can anyone parse that sentence please? Was this article written by GPT-3?

probably->problem is a typo, and prop drilling is lingo for digging down a large chain of components I think.

Re: The new wave of React state management

#134

Post by wizofaus » Sat, Jul 02, 2022, 7:34 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…

There are definitely examples of UI programming that is more complex than certain APIs that largely perform basic CRUD operations, but I'd strongly disagree either is inherently more complex than the other, it's just that human behaviours and preferences are messy and unpredictable, which means conceptually "simple and elegant" UIs are often not what users actually enjoy using, and this inevitably has impacts at the code level. APIs don't have to designed to deal with human eccentricities as they're written for developers, and we aren't like normal people.

Re: The new wave of React state management

#135

Post by rpeden » Sat, Jul 02, 2022, 7:35 PM UTC

andrewljohnson wrote: post #133

DonHopkins wrote: post #127

>For example with local UI state, prop drilling both data and methods to update that data often becomes a probably relatively quickly as things grow. Can anyone parse that sentence please? Was this article written by GPT-3?

probably->problem is a typo, and prop drilling is lingo for digging down a large chain of components I think.

Prop drilling in this context is just passing both state and update function(s) for that state into a component via its props.

Re: The new wave of React state management

#136

Post by dboreham » Sat, Jul 02, 2022, 7:39 PM UTC

cageface wrote: post #85

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…

I was called in to rescue a redux-saga based project that had gone badly off the rails. It was one of the worst codebases I've ever had to work with in many years of coding. Stack traces were useless and debugging with anything higher level than log statements was impossible.

Apparently you don't need to debug if you're a good programmer. This explains why many modern tech stacks (JS, Scala, Kotlin, ...) have a horrible debugging experience.

Re: The new wave of React state management

#137

Post by dboreham » Sat, Jul 02, 2022, 7:41 PM UTC

kizer wrote: post #65

cercatrova wrote: post #53

Earlier quoted context omitted.

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.

You're experiencing the cognitive dissonance from trying to understand unnecessary complexity.

Re: The new wave of React state management

#138

Post by [deleted] » Sat, Jul 02, 2022, 7:44 PM UTC

gernb wrote: post #123

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…

I considered something like this last night as I stay up to 6am working on a new UI library. My conclusion was in part because it's easy. The goal is well defined. I got the first widget working thought I'd call it a day (a night) but then it was so much fun to just implement the next widget mostly because very little design iteration is needed. The problem being solved is well known so each thing to tick off my UI l…

[deleted]

Re: The new wave of React state management

#139

Post by aarpmcgee » Sat, Jul 02, 2022, 7:54 PM UTC

acemarke wrote: post #61

nine_k wrote: post #56

Earlier quoted context omitted.

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.

This looks excellent. I see a lot of potential in the idea of combining the strengths of RTK(+Query) and XState. Thank you for sharing!

Re: The new wave of React state management

#140

Post by Rapzid » Sat, Jul 02, 2022, 7:54 PM UTC

kabes wrote: post #126

m_ke wrote: post #2

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

Mobx has made me finally appreciate frontend programming again. It's like people want to deal with the insanity that is redux only because it's a more pure functional style which react seems to promote.

Something I like to point out to teams when it's the case, and it's often the case, is "When is the last time anyone on the team has used time travel debugging? Never?".