3 ms·

Why can't we just use Model-View-Controller for change-detection? Views subscribe with the model to get notifications about changes to different "aspects" of t

Why can't we just use Model-View-Controller for change-detection? Views subscribe with the model to get notifications about changes to different "aspects" of the model. When they get a change-notification they update themselves by asking the model for its latest data for a given aspect.

mickael-kerjean 3y ago
This is precisely the approach I started on taking to rewrite my oss frontend stuff: https://github.com/mickael-kerjean/filestash/blob/master/public/pages/adminpage/decorator_admin_only.js#L31 https://github.com/mickael-kerjean/filestash/blob/master/pub...
vmware513 3y ago
It is Ember.js, beautifully solving this problem since 2012.
dawnofdusk 3y ago
Literally just Angular if you use RxJS, which the author evidently thinks is too hard to understand and so dismisses it.
mst 3y ago
rxjs (see M. Kerjean's sibling comment for an example) or mobx/mobx-state-tree can be used to implement something like that, and I've quite enjoyed both react+mobx and lit+mobx as a result. (googling 'thing mobx' where 'thing' is your preferred rendering system has results in quite a lot of cases)
phailhaus 3y ago
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.

mickael-kerjean 3y ago

This is precisely the approach I started on taking to rewrite my oss frontend stuff: https://github.com/mickael-kerjean/filestash/blob/master/public/pages/adminpage/decorator_admin_only.js#L31 https://github.com/mickael-kerjean/filestash/blob/master/pub...

vmware513 3y ago

It is Ember.js, beautifully solving this problem since 2012.

dawnofdusk 3y ago

Literally just Angular if you use RxJS, which the author evidently thinks is too hard to understand and so dismisses it.

mst 3y ago

rxjs (see M. Kerjean's sibling comment for an example) or mobx/mobx-state-tree can be used to implement something like that, and I've quite enjoyed both react+mobx and lit+mobx as a result. (googling 'thing mobx' where 'thing' is your preferred rendering system has results in quite a lot of cases)

phailhaus 3y ago

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.