Hacker News Reader

Comment by galaxyLogic | Hacker News Reader

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.

View on HN

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

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

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.

> 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.

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.

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.

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.

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.

> 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.

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)

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

Reply on news.ycombinator.com