Hacker News Reader

Comment by andrewmcwatters | Hacker News Reader

I don’t understand why in web development there’s such a fanatical obsession with “managing state” as if you can’t just place objects somewhere and iterate through them or use browser eventing to tell parts of your app something happened to your data store.

It’s such a weird thing to me. You really need a library that?

From Angular.js to React, I’ve never seen the point other than that it was a sign that you were forced into using a framework’s lifecycle. I’d like to say React is still a library, but it calls your code, so that’s not quite right.

View on HN

The purpose is reactivity: when X state changes, Y needs to update. How do we know which Y's care about which Xes? How do we initialize and clean up those associations as Xes and Y's get created and destroyed? How do we make sure X can't be mutated without triggering Y to update and stay in sync?

This is necessary on the web because it doesn't operate in immediate-mode. React, despite its name, doesn't actually solve the reactivity problem (well, setState and hooks kind of do, but they're pretty basic). The big deal with "state management libraries" like Redux and MobX is that they give you an enshrined container of state that knows how to publish its changes to the things that care about it, in a way that's more performant and ergonomic than the naive approach. That comes with different caveats and constraints depending on the library you choose.

You mentioned events, which can be part of a solution (just like regular callbacks can), but they don't actually solve the hard part of the problem.

This hasn’t been a new concept for decades, though. What you’re describing is why we have event listeners. You dispatch events and only relevant listeners get those events.

You don’t need a library for it.

The “hard part” of the problem is that React doesn’t care about using simple solutions, because it has its own lifecycle you have to use. So inevitably any software that wants to interact with React would have to trigger React to respond to those events.

This architectural decision leads to engineering solutions that make state management seem like a complicated thing, but the “reactivity” issue you’re describing has nothing to do with state management.

It has everything to do with managing React to react to state changes. That’s not state management. That’s framework management.

You don't really have to do anything special with React's lifecycle in order to publish changes... you just call forceUpdate on a component to trigger itself and its children to re-render. The trick is avoiding rendering the parts of that tree which won't actually change. Redux solves this through immutability which allows for reference comparison ("if this component's props didn't change then the object will === the previous one, and we can skip it"). MobX does it by automatically wiring highly granular pub/sub relations between individual variables and the components that reference them.

Additionally, events aren't sufficient on their own because you need the state to actually be stored somewhere, for next time. Events don't hold state, they only pass a transient signal. And if you're manually both a) publishing an event and b) updating the corresponding state, you risk missing a case and having those two get out of sync (not to mention you'll be writing a whole lot of boilerplate logic). It'll also be really hard to change multiple pieces of state at once without having things temporarily disagree. I've worked on a project where this is basically what was done, and it was a nightmare of inconsistent intermediary states and race-conditions.

To put it differently: "state X changed" is a special case of "X happened" that needs quite a few special considerations in practice, and that's why state management abstractions are built atop the more general idea

I appreciate the granular details of what you're saying, but with every sentence, I just think to myself, yeah that's React's problem that it's offloading to others.

Maybe! But that would mean going all-in on the "React is a framework, not a library" thing. Right now they're straddling the line where they can still argue that they're maybe kind of just a library, even if most people don't really buy it at this point

I agree with all the overengineered stuff argument, but this is not as easy as you describe except for the simplest of the use cases.

For example, you might have on screen a component (something inside a modal for example) that might need some data (a newly created record maybe) which is some information that has been dispatched in the past, so either you have to foresee and pre registered every single listener on beforehand or you have to keep track of all the events or the data that was emitted with them. At that point you've invented a new state management solution.

What complex UI isn't obsessed with managing state? Android has definitely moved in a similar direction with RxJava, LiveData, and coroutines. I believe IOS has something similar. Is it possible you've only worked on backend-style projects before? UI programming has different hard parts.

Flux was not handled with scrutiny by the react community. All the implementations of it were weird, so much so that people thought Redux was the least weird of all. Take that for what it’s worth. I consider it the dark ages of React.

Damn, I actually forgot about Flux. It was the dark ages indeed :)

> I’d like to say React is still a library, but it calls your code, so that’s not quite right.

That's exactly what a framework is.

That’s what I’m saying. The developers call it a library, but it’s not. Which is why React has a state management software ecosystem.

If it was, you probably wouldn’t need all of this.

> A JavaScript library for building user interfaces

A word I saw it referred to as in a blogpost somewhere and makes complete sense is that "React is a runtime"

It’s fine if you load each page as an HTTP request, but if your ‘pages’ aren’t real, re-loading everything from an API each time is a bit of a pain.

Reply on news.ycombinator.com