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

301–310 of 310 posts

Re: The new wave of React state management

#301

Post by cehrlich »

erikpukinskis wrote: post #283
cehrlich wrote: post #49

Earlier quoted context omitted.

Agree completely, React Query has made it so much easier to build any kind of app that deals with server state, stuff that would have been extremely challenging to write in the past is now just a couple of lines and works better than before. I personally like using Jotai (if I just want a better version of React Context) or Zustand (if I need a bit more than that) for “client state” alongside React Query, but I’ve al…

What’s wrong with React Context in your opinion?

For anything even slightly complex you need to either use multiple providers or be very careful about rerenders

Re: The new wave of React state management

#302

Post by erikpukinskis »

dqpb wrote: post #225
tunesmith wrote: post #209

I still find the whole subject so frustrating. Being a backend developer that has since out of necessity had to transfer to being a frontend-architect for a team of confused React developers, I'm struck with how the momentum of frontend development quickly leads to very complex state machines. Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. But with…

> Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. Maybe the backend of a crud app is fundamentally simpler than a user-facing UI.

I’ll add to this, there are tough problems that we solve on the front end that the backend could solve, but backend developers run scared from.

For example: most backends will let you query arbitrary data, but they won’t alert you when that query changes.

So we solve this on the frontend (often laboriously, with spaghetti).

IMO backend developers are often unwilling to do anything beyond CRUD… and specifically they are often unwilling to model the dynamics of a domain. They want to treat the domain as frozen in a moment of time.

In general, I would love to see more backend developers be more ambitious about trying to see which jobs the frontend is doing that could be solved on the backend. I think that could distribute some of the workload more evenly, and give BE devs a taste of what that higher level of complexity looks like.

Sometimes I think backend developers just write off hard problems that they could solve because “that’s a frontend concern”. It’s an easy excuse.

Re: The new wave of React state management

#303

Post by wilde »

petilon wrote: post #143
wilde wrote: post #108

Earlier quoted context omitted.

Yeah this. The classic is unread state in a mail app. Unread state is usually displayed both as bold state per message in a message list, and as a count in the folder list. These need to stay in sync as the user reads mail (and sometimes marks read state explicitly). Two views of the same underlying state.

Sure, you can come up with an example where some synchronization is needed, but how often do you have this requirement? In most apps it is rare, which means that it can be solved by using a couple of extra lines of code to update the screen, as opposed to adopting a complex state management system with events firing and so on. Simple solutions for simple problems.

It is quite common. Take this screenshot of Youtube: https://imgur.com/a/nxGdcWj

The comments total at the top and each of the thread counts need to be kept in sync with their corresponding inline list representations.

Most lists in apps display a total count summary. This is even more common on desktop, where you have room to display more info.

Re: The new wave of React state management

#304

Post by runes »

hakfoo wrote: post #230
tunesmith wrote: post #209

I still find the whole subject so frustrating. Being a backend developer that has since out of necessity had to transfer to being a frontend-architect for a team of confused React developers, I'm struck with how the momentum of frontend development quickly leads to very complex state machines. Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. But with…

That's always something I've found weird. There are things that are "global state", at least in the sense that you're likely to care about them in a hundred disparate places. If you're writing a UI, odds are at some point you're going to want to see "current user ID", "language selection", etc. Why can't we just say "it's global" rather than doing all sorts of plumbing to pipe these details around the code base? I kn…

This reminds me of a mithril project where my state management library was just a global variable. It was a breath of fresh air: simple code, snappy UI, no convoluted debugging.

Re: The new wave of React state management

#305

Post by toastercat »

runes wrote: post #304
hakfoo wrote: post #230

Earlier quoted context omitted.

That's always something I've found weird. There are things that are "global state", at least in the sense that you're likely to care about them in a hundred disparate places. If you're writing a UI, odds are at some point you're going to want to see "current user ID", "language selection", etc. Why can't we just say "it's global" rather than doing all sorts of plumbing to pipe these details around the code base? I kn…

This reminds me of a mithril project where my state management library was just a global variable. It was a breath of fresh air: simple code, snappy UI, no convoluted debugging.

Yep, Mithril's redraw system is definitely one of its strengths since there is no plumbing necessary. You're free to do whatever you want without any weird adapter libraries. You can build some decently robust state containers without dependencies or Mithril-specific code[1].

[1] https://mithril-by-examples.js.org/examples/tweeter-box/

Re: The new wave of React state management

#306

Post by slorber »

I read the whole article, and I found it quite interesting and it has a lot of good references that I've encountered in the past (for example Zombie Children etc...)

However I find it very difficult to read: there's so much text and not many example to illustrate.

Re: The new wave of React state management

#307

Post by blindmute »

gofreddygo wrote: post #281
blindmute wrote: post #278

Earlier quoted context omitted.

An external service fetcher doesn't have integration with React because the entire tree potentially needs to know when the data changed. Once you write the code to subscribe to those changes where necessary, you've basically invented another state library.

* Service fetcher does fetching and updating store * Component does subscribing * React does updating component tree with changes. If a component wants changes it must subscribe. If not, it doesn't. If there is a change, subscribed components get updates. If not, they don't. Responses are (conditionally) cached in the store by its respective service. Any component that wants data just asks the service. Service fetche…

> What is react query's role here ?

Its role is to do everything you just said in one package, plus other networking features. It fetches, updates the store, subscribes the components, caches the responses, performantly rerenders. It allows configuration of when to refetch, how to cache, polling, pagination, infinite scroll, etc etc via a simple API.

Nothing is stopping you from writing all this yourself, but libs exist for a reason. It's a terribly useful networking package. If you just use a generic store and write a fetcher yourself, you have to at the very least write logic for when to (re)fetch and for persisting the responses to the store.

Re: The new wave of React state management

#309

Post by erikpukinskis »

gofreddygo wrote: post #297
erikpukinskis wrote: post #285

Earlier quoted context omitted.

You’re hand-waving away “subscribing” as if it’s not a time bomb. The set of possible events any given query might need to subscribe to is massive. Yes, you can build a large app with a pub/sub model but the number of subscriptions runs away from you and it gets really hard to know which of 1000 subscriptions you need to refresh when an association between two random pieces of data is created/deleted. Associations ar…

That's a sensible response, so thanks for that. Being hard to define and manage subscriptions is a problem, a bigger deeper problem that react query or any other lib isn't solving. By "set of possible events any given query might need to subscribe to is massive" i assume you meant "component" and not query, if not then i don't know what that means, if yes, that component needs refactoring. I'm interested in libraries…

I do mean “query”. I am presuming you want every query in your app to live update when the results change. The problem I’m indicate is: how do you know which queries are invalid after any given event?

Re: The new wave of React state management

#310

Post by SZJX »

Feedback for the author (who seems to have also made the submission): The content is good, but there are too many basic typos and grammatical mistakes in the article, making it really hard to follow at times. Not sure if it was written in another language in the first place. Please run your article through some spellchecker and grammar checker the next time, not to mention finding somebody to proofread it.
Post reply on HN