4 ms·

It's exciting & unsurprising to me that state is such an unsolved problem. For the longest time React was kind of in denial to a large degree about what they w

It's exciting & unsurprising to me that state is such an unsolved problem. For the longest time React was kind of in denial to a large degree about what they were. They called themselves a View library. Hooks have definitely noticeably changed that relationship, & how people integrate app state with React, but the problem here of updating hasn't really changed all that much. It's not a new thing either. A lot of the initial resistance to React & the VDOM was that it felt like unnecessary work. Because so many frameworks at the time were working towards two-way data-binding systems, which aren't necessarily but were often associated with with smaller, precise DOM updates. HP/LG's WebOS's underlying Enyo project was one high profile would be effort here. Signals have definitely been a good re-grouping point, for reconsidering what the shape of things might look like, for trying to do a better job. I'm a bit surprised we're still operating so much at a library level regarding reactive systems/signals. JavaScript objects have quite a lot of flexibility already, and the addition of Proxies added a lot of capabilities. Faint/distanct memory, but I think Proxies were justification for killing Object.observe[1]: now users could do whatever they wanted, so we no longer needed a JS native way to see objects change. Yet, we're still very library based, rather than trying to make objects themselves better, more reactable. [1] http://web.archive.org/web/20200218195131/https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/observe http://web.archive.org/web/20200218195131/https://developer....

PaulHoule 4y ago
There is context which wages a war against debugging and testing, for one thing. React has no real answer to state going sideways. Then there is controlled/uncontrolled component which is an example of structural instability (what looks like a tiny change to your boss is a bigger deal than it should be) unless you ride the crazy train and use “plain ordinary javascript” to build a parallel system to move (some of) the state around.
- rektide 4y ago
  One of the main reasons I was so hopeful for Object.observe was because it would have been a stable language feature to build better debuggers around. Instead, it feels like most state management libraries ultimately end of writing their own Chrome extensions. Which now that I say that makes me curious: do any of these executions also let you observe/monitor server-side state management systems?
- WiseWeasel 4y ago
  You can often use route params or location hash for communicating state sideways if shared context is overkill, with the benefit of making the state bookmarkable or accessible in the history.
  - CharlieDigital 4y ago
    That's only sustainable for small pieces of state or some mechanism to exchange that small piece of state for a more complete piece of state.
    - PaulHoule 4y ago
      Right, the problem with React is it has no global answer for application state, instead it provides a toolbox with which it is possible to set up your own state handling but frequently you face structural instability where a small change in your app’s functionality require large architectural changes.
    - rektide 4y ago
      > or some mechanism to exchange that small piece of state for a more complete piece of state using links to refer to information is, like, not a totally foreign concept to the web (and certainly granted: in some cases this issue of signaling via url can get quite ugly; but often it's not).
- javcasas 4y ago
  If you are having trouble testing context, you are _definitely_ doing context wrong. To test the context itself: pass as children of the context components to render the context state. To test the components within the context: create a context with mock functions/values. React has no answer to state going sideways because React manages a tree of components, and you are not supposed to connect random branches of a tree. That would completely break the concept of tree, container/contained, and just convert everything into a graph, and graphs are much harder to deal with. BTW, HTML is a tree, not a graph. Controlled vs uncontrolled and the boss demanding a tiny change is just another case of bosses not knowing about how it works the system and imagining things and then demanding reality to conform to their imagination. Not an issue with React.
  - PaulHoule 4y ago
    For the goals of the application you can push a button in one branch of the tree and it has an impact on many other branches…
    - pas 4y ago
      That still means you have 3 different types of entities. One where the event originates (knobs), one where it will gets translated into actual UX effects (DOM updates, API fetches, whatever, lets call these servos and gauges), and one place where the business logic lives that transforms between the low-voltage input signal and the high-voltage output driver power. Without that transducer you have incompatible things. Yes, many times this is a trivial thing, and that's usually when it can be done internally to the component.
      - PaulHoule 4y ago
        That is one of the many partial answers that works some of the time but not all of the time. For relatively simple applications you can push all the state high up to the root of the tree or near the root of the tree and have it flow down with props. There is a complexity hierarchy and around the time people woke up to AJAX (there were a few years when it was just a ‘evil Microsoft thing’) I was writing apps that were highly dynamic, the extreme example is an IDE with property sheets or something like Adobe Photoshop where an arbitrary number of components need to ‘react’ when a piece of data changes. It is bad enough when there is a status bar and four other parts of the UI determined by management that need to be updated when a piece of data changes (could become five or six tomorrow). it is worse when the user can instantiate arbitrary components (say for a knowledge graph editor or a geospatial intelligence tool) that ‘listen’ to event changes. Prior to 2010 I was building apps like that and developing special purpose frameworks to do exactly as you say in GWT, Silverlight and such. There was no support for such things at the time, no async/await, management and other devs had no idea of the ‘race conditions’ that could happen when data could either come out of a cached copy or get fetched. In those cases I spent a while struggling to understand the problem and developed systems for handling state in complex applications so when I look at React, Vue and most of those (with the possible exception of MobX) I want to ask “where’s the beef?” because these frameworks are not adequate to the problem and people don’t seem to understand they are no adequate to the problem (it comes from Facebook, how bad can it be?) Most of the reason why people think "React is OK" is that they are writing apps (99% of them) that are so simple they don't need React. If you're writing apps that really need React, than React doesn't seem OK.

PaulHoule 4y ago

There is context which wages a war against debugging and testing, for one thing. React has no real answer to state going sideways. Then there is controlled/uncontrolled component which is an example of structural instability (what looks like a tiny change to your boss is a bigger deal than it should be) unless you ride the crazy train and use “plain ordinary javascript” to build a parallel system to move (some of) the state around.

rektide 4y ago
One of the main reasons I was so hopeful for Object.observe was because it would have been a stable language feature to build better debuggers around. Instead, it feels like most state management libraries ultimately end of writing their own Chrome extensions. Which now that I say that makes me curious: do any of these executions also let you observe/monitor server-side state management systems?
WiseWeasel 4y ago
You can often use route params or location hash for communicating state sideways if shared context is overkill, with the benefit of making the state bookmarkable or accessible in the history.
- CharlieDigital 4y ago
  That's only sustainable for small pieces of state or some mechanism to exchange that small piece of state for a more complete piece of state.
  - PaulHoule 4y ago
    Right, the problem with React is it has no global answer for application state, instead it provides a toolbox with which it is possible to set up your own state handling but frequently you face structural instability where a small change in your app’s functionality require large architectural changes.
  - rektide 4y ago
    > or some mechanism to exchange that small piece of state for a more complete piece of state using links to refer to information is, like, not a totally foreign concept to the web (and certainly granted: in some cases this issue of signaling via url can get quite ugly; but often it's not).
javcasas 4y ago
If you are having trouble testing context, you are _definitely_ doing context wrong. To test the context itself: pass as children of the context components to render the context state. To test the components within the context: create a context with mock functions/values. React has no answer to state going sideways because React manages a tree of components, and you are not supposed to connect random branches of a tree. That would completely break the concept of tree, container/contained, and just convert everything into a graph, and graphs are much harder to deal with. BTW, HTML is a tree, not a graph. Controlled vs uncontrolled and the boss demanding a tiny change is just another case of bosses not knowing about how it works the system and imagining things and then demanding reality to conform to their imagination. Not an issue with React.
- PaulHoule 4y ago
  For the goals of the application you can push a button in one branch of the tree and it has an impact on many other branches…
  - pas 4y ago
    That still means you have 3 different types of entities. One where the event originates (knobs), one where it will gets translated into actual UX effects (DOM updates, API fetches, whatever, lets call these servos and gauges), and one place where the business logic lives that transforms between the low-voltage input signal and the high-voltage output driver power. Without that transducer you have incompatible things. Yes, many times this is a trivial thing, and that's usually when it can be done internally to the component.
    - PaulHoule 4y ago
      That is one of the many partial answers that works some of the time but not all of the time. For relatively simple applications you can push all the state high up to the root of the tree or near the root of the tree and have it flow down with props. There is a complexity hierarchy and around the time people woke up to AJAX (there were a few years when it was just a ‘evil Microsoft thing’) I was writing apps that were highly dynamic, the extreme example is an IDE with property sheets or something like Adobe Photoshop where an arbitrary number of components need to ‘react’ when a piece of data changes. It is bad enough when there is a status bar and four other parts of the UI determined by management that need to be updated when a piece of data changes (could become five or six tomorrow). it is worse when the user can instantiate arbitrary components (say for a knowledge graph editor or a geospatial intelligence tool) that ‘listen’ to event changes. Prior to 2010 I was building apps like that and developing special purpose frameworks to do exactly as you say in GWT, Silverlight and such. There was no support for such things at the time, no async/await, management and other devs had no idea of the ‘race conditions’ that could happen when data could either come out of a cached copy or get fetched. In those cases I spent a while struggling to understand the problem and developed systems for handling state in complex applications so when I look at React, Vue and most of those (with the possible exception of MobX) I want to ask “where’s the beef?” because these frameworks are not adequate to the problem and people don’t seem to understand they are no adequate to the problem (it comes from Facebook, how bad can it be?) Most of the reason why people think "React is OK" is that they are writing apps (99% of them) that are so simple they don't need React. If you're writing apps that really need React, than React doesn't seem OK.