3 ms·

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 thro

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.

theandrewbailey 5y ago
> 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.
- andrewmcwatters 5y ago
  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
- omniscient_oce 5y ago
  A word I saw it referred to as in a blogpost somewhere and makes complete sense is that "React is a runtime"
thomasedwards 5y ago
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.
runawaybottle 5y ago
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.
- ilucin 5y ago
  Damn, I actually forgot about Flux. It was the dark ages indeed :)
brundolf 5y ago
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.
- andrewmcwatters 5y ago
  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.
  - brundolf 5y ago
    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
iudqnolq 5y ago
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.

theandrewbailey 5y ago

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

andrewmcwatters 5y ago
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
omniscient_oce 5y ago
A word I saw it referred to as in a blogpost somewhere and makes complete sense is that "React is a runtime"

thomasedwards 5y ago

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.

runawaybottle 5y ago

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.

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

brundolf 5y ago

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.

andrewmcwatters 5y ago
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.
- brundolf 5y ago
  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

iudqnolq 5y ago

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.