The new wave of React state management • Hacker News Board

Re: The new wave of React state management

#291

Post by mixmastamyk » Sun, Jul 03, 2022, 5:26 PM UTC

chrisco255 wrote: post #290

mixmastamyk wrote: post #199

Earlier quoted context omitted.

We certainly had network programming in the 90s. It was just that apps didn't use it unless needed. SGI res was typically 1280x1024 and Wacom tablets were common in studio/professional settings.

Apps didn't use it because it wasn't practical or in high demand yet. People were just getting used to checking email and most people were only intermittently online via dial up. Collaborative apps would take another 8 or 9 years to really start to take off.

We had T-1 internet to every desk in ‘94 and I used dozens of networking apps from archie to veronica. Probably used CU SeeMe before a browser. Though Mosaic dropped around that time.

Advanced collaboration still in the future, this era was more like chat and file transfer. I think you could mark up Word docs from a network drive at some point.

Re: The new wave of React state management

#292

Post by andrewstuart2 » Sun, Jul 03, 2022, 6:21 PM UTC

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…

It really should be global, if it's global state. Maybe not directly in the javascript global (window) context, but part of a shared singleton, in an obvious (or at least consistent) way, or similar.

The simplest and most obvious pattern I've ever used was essentially an angularjs (1.x) directive that allowed templates to grab named references to services and directly reference that state. Mutations were also exposed on the services as plain old functions, and it all just kind of worked. Looking at a template, it was blatantly obvious where the data and methods came from. The two way binding just made it dead simple to grok what was going on once all the layers of abstraction (controllers in the AngularJS world) that might rename things or make up new clever abstractions were gone.

I've built with React a half dozen times now, and I still haven't found anything that got me close to that level of simplicity. I'd say most of my experience has been that it's at least 10x more complex with all the gymnastics you have to do to keep the data flow unidirectional.

Re: The new wave of React state management

#293

Post by [deleted] » Sun, Jul 03, 2022, 7:52 PM UTC

proxyon wrote: post #252

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.

You are literally complaining about Computer Science

[deleted]

Re: The new wave of React state management

#294

Post by thatswrong0 » Sun, Jul 03, 2022, 11:29 PM UTC

lifeplusplus wrote: post #265

theteapot wrote: post #253

Earlier quoted context omitted.

> I believe the worst part is redux .. And hooks. Sorry but React started to go crazy when hooks IMHO.

I had a project where state was coming through redux, from parents via props, context somewhere from parent elements, xhr fetch/graphql, local storage... Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions

React components don't function like regular JS functions, but look like regular functions. So that's obviously not a legitimate knock against them - you're working within the React runtime. It's not normal Javascript.

And lifecycle methods are just as "magical" as hooks. If you just thought about why the "rules of hooks" exist for a moment instead of just hating change for the sake of it existing, you could probably intuit how they work under the hood.

Lastly, lifecycle methods don't allow you to co-locate feature-related code, can actually create more bugs (if you have logic in `componentDidMount` but forget to add something similar to `componentDidUpdate` for example), and any logic contained within lifecycle methods isn't composable / reusable.

I really don't understand where you're coming from at all with this.

Re: The new wave of React state management

#295

Post by bernawil » Mon, Jul 04, 2022, 2:39 AM UTC

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…

I think this is a bad take on an old premise. It's not that "global state is bad", rather, "global MUTABLE state is bad". Which is kind of right but for the wrong reasons. Truth is, "mutable state" is bad and "mutable global state" is even worse. That comes from the old times of OOP when people insisted in "encapsulating" state and relied on mutation.

It's sort of a logical fallacy. How could global state be bad if reading from a database o an API is essentially that? The problem is mutation, that if global state is mutated somewhere, other places that read the same state don't know about it.

Modern state managment instead is immutable and is not even an original idea of React. Redux was basically copied from Elm's state management.

Re: The new wave of React state management

#296

Post by lifeplusplus » Mon, Jul 04, 2022, 3:30 AM UTC

thatswrong0 wrote: post #294

lifeplusplus wrote: post #265

Earlier quoted context omitted.

I had a project where state was coming through redux, from parents via props, context somewhere from parent elements, xhr fetch/graphql, local storage... Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions

React components don't function like regular JS functions, but look like regular functions. So that's obviously not a legitimate knock against them - you're working within the React runtime. It's not normal Javascript. And lifecycle methods are just as "magical" as hooks. If you just thought about why the "rules of hooks" exist for a moment instead of just hating change for the sake of it existing, you could probably…

React should act like a framework/library, not become a transpiler and create javascript 2.0. It's hugely confusing, and harder to reason. I shouldn't have to learn about internals of the library to figure out what's wrong with my code. it's a smell of bad library, this wasn't the problem when simple class functions were used as lifecycle methods.

Re: The new wave of React state management

#297

Post by gofreddygo » Mon, Jul 04, 2022, 6:05 AM UTC

erikpukinskis wrote: post #285

gofreddygo wrote: post #281

Earlier quoted context omitted.

* 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…

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 not because of what it can do for my code or me or my team but what problem it solved for the team that needed it in the first place, bad enough to write a lib for it. I want to avoid those problems.

I start with importing libs for quick TAT and slowly replace them with a few hundred lines of code that i can understand, modify, debug, monitor, unit and integration test. I usually end up redefining or better defining the problem and rescoping the issue to not needing to solve said problems.

Most libs do NOT provide that level of valuable solutions to worthy problems to go keep them around as deps. Deps are not free and have no liability to me or my code. React query is one more in that long list. IMHO.

Re: The new wave of React state management

#298

Post by shirogane86x » Mon, Jul 04, 2022, 12:37 PM UTC

theteapot wrote: post #253

42e6e8c8-f7b8-4 wrote: post #179

Earlier quoted context omitted.

I believe the worst part is redux. React is mostly reasonable. Redux is massive boilerplate.

> I believe the worst part is redux .. And hooks. Sorry but React started to go crazy when hooks IMHO.

As someone who didn't get react at all before hooks, and still doesn't 100% get react with class components (but is quite proficient with hooks) what's the issue with hooks specifically? genuinely curious. I find react with class components very messy, and especially in the basic components, I find useState + useEffect a lot cleaner and easy to reason about than setState and all the lifecycle hooks...

Re: The new wave of React state management

#299

Post by shirogane86x » Mon, Jul 04, 2022, 12:41 PM UTC

Rapzid wrote: post #140

kabes wrote: post #126

Earlier quoted context omitted.

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

I actually made pretty extensive use of the redux time travelling debugger at my last job, I found it to be very convenient, especially as the application got bigger and more convoluted - not really because of development issues, but just general feature creep (features were being sold left and right by a less than stellar marketing team)

Re: The new wave of React state management

#300

Post by wizofaus » Mon, Jul 04, 2022, 1:09 PM UTC

jitl wrote: post #287

wizofaus wrote: post #264

Earlier quoted context omitted.

Then you've never written APIs that have to do super complex calculations or process huge amounts of data efficiently and reliably. By far the most complex code I've had to deal with has been "back-end engine" type code, even if it was technically part of a desktop application (but wasn't dealing with user interactions).

My point isn't that "all UI is more complex than all API", but that the constraints and nature of UI tend towards complexity (especially incidental complexity) at a higher rate than API programming. As you observed in a previous post, UI engineers struggle to use techniques like end-to-end testing that API engineers use with relative ease. Why is that? My argument is that engineers working in the API space more compl…

I don't disagree with anything you've written there, but I still disagree that UI code is typically or inherently more complex (or harder to write well) than backend code. I doubt it's anything you can even prove one way or another. But while the nature of inputs and outputs for UI code tends to be nebulous and somewhat poorly defined, it's hard to argue the range of possible inputs compares with code that has to process massive datasets.