3 ms·

Sounds simple, right? It fails horribly, because you lose control of how data flows through your application. One view triggers an update to a model, which will

Sounds simple, right? It fails horribly, because you lose control of how data flows through your application. One view triggers an update to a model, which will immediately trigger other views to render regardless of where they exist in the component hierarchy or whether there are more changes to make in tandem. This can cascade to other updates, and suddenly you're in a weird intermediate state caused by a race condition between two separate views that's incredibly difficult to debug. The reason why solutions like React are so popular is because it radically simplifies state management: data flows in from the top of the component hierarchy down. When a component makes changes to state, those changes are queued up for the next consistent render loop, which ensures that nothing renders in an intermediate state. An entire class of bugs, gone.

galaxyLogic 3y ago
> One view triggers an update to a model, I think it should be only the Controller which changes the Model. That can cause views which are dependent on the "aspect" of the model that was changed to update themselves. But a view updating itself should NOT cause the model to change and thus not cause a cascade of other views causing other views to change.
- phailhaus 3y ago
  That's still a problem, because a view can trigger multiple controller updates (perhaps across controllers!), which need to be batched so that the application data remains in a consistent state.
  - galaxyLogic 3y ago
    I don't think that's the case in proper MVC design. Perhaps in some web version of it. In proper MVC AFAIK view never triggers any changes to anything, it just displays things and updates only itself, not others.
    - phailhaus 3y ago
      How can you build anything interactive if your views never trigger updates to state? Here's a simple example: I have a reusable filter component. It lets you enter text and choose an option. Sure, it can manage that state internally, but at some point it needs to communicate out the chosen option to its parent component, which needs to update its own state to reflect the filter value and handle the filtering. In MVC, you need the controller to maintain state, and the views need to be able to hook into it.
      - galaxyLogic 3y ago
        In MVC it is the Controller which handles all the events that happen upon the view. The view-"object" itself only does displaying, including updates to itself. So a change in how the view looks does not trigger anything, it is user-actions caught by the Controller which do. These are the basic principles of MVC. I don't know if you are using React or what, where the terms like View and Controller might have a different meaning, than in classic MVC. My question more is about does React et al. use the principles of MVC and if not why not, and if yes why is a basic MVC framework not all we need to do change-handling.
        phailhaus 3y ago
        > it is user-actions caught by the Controller which do OK, and how does this work? The view is rendering the filter box, allowing the user to select an option. How does the Controller know what option was selected, if the view is not registering a click handler and communicating this up? What ends up happening is that as your application grows, so does the number of controllers, models, and views. A user action in one view can cascade to many different controller updates, which can overlap and conflict in difficult-to-debug ways, and render inconsistent data states. Flux architecture solves this, which is roughly what React is based on.

galaxyLogic 3y ago

> One view triggers an update to a model, I think it should be only the Controller which changes the Model. That can cause views which are dependent on the "aspect" of the model that was changed to update themselves. But a view updating itself should NOT cause the model to change and thus not cause a cascade of other views causing other views to change.

phailhaus 3y ago
That's still a problem, because a view can trigger multiple controller updates (perhaps across controllers!), which need to be batched so that the application data remains in a consistent state.
- galaxyLogic 3y ago
  I don't think that's the case in proper MVC design. Perhaps in some web version of it. In proper MVC AFAIK view never triggers any changes to anything, it just displays things and updates only itself, not others.
  - phailhaus 3y ago
    How can you build anything interactive if your views never trigger updates to state? Here's a simple example: I have a reusable filter component. It lets you enter text and choose an option. Sure, it can manage that state internally, but at some point it needs to communicate out the chosen option to its parent component, which needs to update its own state to reflect the filter value and handle the filtering. In MVC, you need the controller to maintain state, and the views need to be able to hook into it.
    - galaxyLogic 3y ago
      In MVC it is the Controller which handles all the events that happen upon the view. The view-"object" itself only does displaying, including updates to itself. So a change in how the view looks does not trigger anything, it is user-actions caught by the Controller which do. These are the basic principles of MVC. I don't know if you are using React or what, where the terms like View and Controller might have a different meaning, than in classic MVC. My question more is about does React et al. use the principles of MVC and if not why not, and if yes why is a basic MVC framework not all we need to do change-handling.
      - phailhaus 3y ago
        > it is user-actions caught by the Controller which do OK, and how does this work? The view is rendering the filter box, allowing the user to select an option. How does the Controller know what option was selected, if the view is not registering a click handler and communicating this up? What ends up happening is that as your application grows, so does the number of controllers, models, and views. A user action in one view can cascade to many different controller updates, which can overlap and conflict in difficult-to-debug ways, and render inconsistent data states. Flux architecture solves this, which is roughly what React is based on.