4 ms·

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 d

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.

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.