6 ms·

The "state management problem" appears to be an invention of React. This didn't use to be a problem with MVC. The state lives on the server. When state changes

The "state management problem" appears to be an invention of React. This didn't use to be a problem with MVC. The state lives on the server. When state changes it should be persisted on the server immediately (in case the user unexpectedly closes the browser). On the client all you need is a cache. With MVC, each page is more or less independent. Each page gets the data it needs from the server (through a client-side cache), then updates the server when something changes. No "state management problem". In contrast, ReactRouter sees the entire application as one humungous component. Therein lies the problem.

jitl 4y ago
I came to understand MVC (model-view-controller) from writing Objective-C desktop software (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html https://developer.apple.com/library/archive/documentation/Ge...). The “M” in that MVC is “Model”, which is the same idea as “state management”. It’s an object that stores state and notifies listeners when it changes. You can think of these libraries as ways to implement the “Model” concern in the application. But from your use of MVC, I think you are referring to server-side MVC, where the “V” is a rendered HTML template? I’m not sure how to square the desktop software version of MVC with your assertion that state should only exist on the server. My Cocoa desktop apps ran fine 10 years ago without a server. The React application I work on today has many bits of local state it needs to track like “what is selected?”, “how wide is the sidebar?”, and “should this menu be open?”. I don’t think the server should be involved in such matters.
- petilon 4y ago
  I am talking about client-side MVC. Models should be POJO [1], no library needed. [1] https://en.wikipedia.org/wiki/Plain_old_Java_object https://en.wikipedia.org/wiki/Plain_old_Java_object
wilde 4y ago
This is true until your customers complain that your UI is super slow. You realize they’re trying to use your app from a cell phone with poor service. So you have the genius idea to add optimistic updates in JS. Now you have all the problems from the article since you need to update all the components everywhere on screen that share state.
- petilon 4y ago
  All you need is a client-side cache.
  - wilde 4y ago
    How do changes to that cache get displayed? Your cache emits events that each UI element has to listen to? Congrats you’re using redux! (It would perhaps be more accurate to say that React folks had to reinvent these patterns, but the problems were definitely present in the postback era)
    - petilon 4y ago
      > Your cache emits events that each UI element has to listen to? It doesn't. How often do you have the same information redundantly displayed in multiple places, on the same screen?
      - ativzzz 4y ago
        It's not even necessarily the same information, but small pieces of one bigger piece that need to be updated once some of the other smaller pieces change
        wilde 4y ago
        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.
        petilon 4y ago
        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.
bcherny 4y ago
Your causation is reversed. People demanded more interactive web apps, which led to more stateful UI, which led to React. In the case of Facebook, the motivating app was Ads Manager — an enormous, highly interactive single page app for advertisers. You couldn’t build something like it with HTML + server endpoints; in the pre-web days, apps with this kind of complexity would be desktop apps. Google Docs, Google Sheets, Maps, Spotify — these all have a huge amount of client-side state. You can’t represent that state on the server without making the UI unusably slow. The need to build these kinds of apps in a portable way led to complex state, which React tried to address (so did Angular, Ember, Backbone, etc.).
- petilon 4y ago
  > You can’t represent that state on the server without making the UI unusably slow. And that's why you use a client-side cache.
  - kaoD 4y ago
    And that's why you need state management. Cache is state.
  - xeromal 4y ago
    And once that cache is sufficiently complex, it's just a state store like redux.
    - petilon 4y ago
      Cache stays simple even for large applications. It never gets "sufficiently complex".
      - xeromal 4y ago
        Theoretically, but not practically.
      - ekidd 4y ago
        As the joke goes, there are two hard problems in software: 1. Naming things. 2. Cache invalidation. 3. Off-by-one errors. Caches are tricky beasts. First, you need to update them when the server-side state changes (for example, two people editing a single Google doc). Second, writing state changes to the server and waiting for confirmation is too slow for many kinds of interactions. In these cases, it's typical to optimistically write local changes to a local store, and then try to sync those changes with server asynchronously. But if synchronization fails, then the client needs to report that. And finally, there's the problem of partially loaded state, where the rest is loaded asynchronously on demand. That should be simple, but without some kind of framework, it also tends to have lots of subtle state-machine and null-reference bugs. So, no, cache does not always stay simple in large applications. (Unless the app is read only, and you're OK showing stale data.)
pweissbrod 4y ago
I used to think the same thing until I considered that single page app development is really just a reinvention of thick clients. When you look at an SPA as a thick client state management is a natural thing as it was in Java swing and WPF and Windows forms and other stacks beyond my knowledge
s-lambert 4y ago
React wasn't the first complex frontend framework, arguably people were having these state management problems ever since people started doing more stuff like jQuery UI. It's not tied to SPAs either, you can have state management problems for a single URL as long as it has any form of state change (like opening a modal).

jitl 4y ago

I came to understand MVC (model-view-controller) from writing Objective-C desktop software (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html https://developer.apple.com/library/archive/documentation/Ge...). The “M” in that MVC is “Model”, which is the same idea as “state management”. It’s an object that stores state and notifies listeners when it changes. You can think of these libraries as ways to implement the “Model” concern in the application. But from your use of MVC, I think you are referring to server-side MVC, where the “V” is a rendered HTML template? I’m not sure how to square the desktop software version of MVC with your assertion that state should only exist on the server. My Cocoa desktop apps ran fine 10 years ago without a server. The React application I work on today has many bits of local state it needs to track like “what is selected?”, “how wide is the sidebar?”, and “should this menu be open?”. I don’t think the server should be involved in such matters.

petilon 4y ago
I am talking about client-side MVC. Models should be POJO [1], no library needed. [1] https://en.wikipedia.org/wiki/Plain_old_Java_object https://en.wikipedia.org/wiki/Plain_old_Java_object

wilde 4y ago

This is true until your customers complain that your UI is super slow. You realize they’re trying to use your app from a cell phone with poor service. So you have the genius idea to add optimistic updates in JS. Now you have all the problems from the article since you need to update all the components everywhere on screen that share state.

petilon 4y ago
All you need is a client-side cache.
- wilde 4y ago
  How do changes to that cache get displayed? Your cache emits events that each UI element has to listen to? Congrats you’re using redux! (It would perhaps be more accurate to say that React folks had to reinvent these patterns, but the problems were definitely present in the postback era)
  - petilon 4y ago
    > Your cache emits events that each UI element has to listen to? It doesn't. How often do you have the same information redundantly displayed in multiple places, on the same screen?
    - ativzzz 4y ago
      It's not even necessarily the same information, but small pieces of one bigger piece that need to be updated once some of the other smaller pieces change
      - wilde 4y ago
        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.
        petilon 4y ago
        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.

bcherny 4y ago

Your causation is reversed. People demanded more interactive web apps, which led to more stateful UI, which led to React. In the case of Facebook, the motivating app was Ads Manager — an enormous, highly interactive single page app for advertisers. You couldn’t build something like it with HTML + server endpoints; in the pre-web days, apps with this kind of complexity would be desktop apps. Google Docs, Google Sheets, Maps, Spotify — these all have a huge amount of client-side state. You can’t represent that state on the server without making the UI unusably slow. The need to build these kinds of apps in a portable way led to complex state, which React tried to address (so did Angular, Ember, Backbone, etc.).

petilon 4y ago
> You can’t represent that state on the server without making the UI unusably slow. And that's why you use a client-side cache.
- kaoD 4y ago
  And that's why you need state management. Cache is state.
- xeromal 4y ago
  And once that cache is sufficiently complex, it's just a state store like redux.
  - petilon 4y ago
    Cache stays simple even for large applications. It never gets "sufficiently complex".
    - xeromal 4y ago
      Theoretically, but not practically.
    - ekidd 4y ago
      As the joke goes, there are two hard problems in software: 1. Naming things. 2. Cache invalidation. 3. Off-by-one errors. Caches are tricky beasts. First, you need to update them when the server-side state changes (for example, two people editing a single Google doc). Second, writing state changes to the server and waiting for confirmation is too slow for many kinds of interactions. In these cases, it's typical to optimistically write local changes to a local store, and then try to sync those changes with server asynchronously. But if synchronization fails, then the client needs to report that. And finally, there's the problem of partially loaded state, where the rest is loaded asynchronously on demand. That should be simple, but without some kind of framework, it also tends to have lots of subtle state-machine and null-reference bugs. So, no, cache does not always stay simple in large applications. (Unless the app is read only, and you're OK showing stale data.)

pweissbrod 4y ago

I used to think the same thing until I considered that single page app development is really just a reinvention of thick clients. When you look at an SPA as a thick client state management is a natural thing as it was in Java swing and WPF and Windows forms and other stacks beyond my knowledge

s-lambert 4y ago

React wasn't the first complex frontend framework, arguably people were having these state management problems ever since people started doing more stuff like jQuery UI. It's not tied to SPAs either, you can have state management problems for a single URL as long as it has any form of state change (like opening a modal).