Not the Elm Architecture, but I found this a very good article on how MVC differs from unidirectional approaches: https://www.futurice.com/blog/reactive-mvc-and-the-virtual-d...
In MVC, the model-view communication is not "interactive" as defined by the article (source pushes to sink). Instead, the view pulls data from the model. There is only a general #changed notification to let the view know that the model has changed.
So "unidirectional" approaches fix the problems you get when you don't understand MVC. ¯\_(ツ)_/¯
It would seem that React runs quite differently than Vue deep under the hood, am I missing something?
I appreciated the alternative view from the article, as I like to know where things are going, and his criticisms of React seemed valid, but I am new enough to this environment to need clarifications on complex claims.
All the pieces have a single responsibility, the view reacts to model changes and redraw itself, the controller executes the business logic on UI events and the model to broadcast events when its state has/was changed by the controller. Data flows only in one direction.
In Flux/redux the unidirectional nature comes from all updates targeting and emanating from a single source (store), and being routed to views accordingly. An interaction from one component will never result in a disconnect where you failed to update the correct model(s) or to notify the right components of a change (hi Backbone.js).
> have multiple data sources feeding into a myriad of components,
Why? Certainly my MVC apps have a single "store" that's the source of truth, and I would say that what you describe is not following the MVC pattern.
"In this metaphor, views deal with everything graphical; they request data from their model, and display the data."[1]
Also, the View should only make a note that it needs to be refreshed (Cocoa for example has the convenient "needsDisplay" boolean property on Views), not actually do the refresh on notification. I see the latter a lot, so you have the model effectively calling refresh on the view, so pushing updates. That ain't MVC, in MVC the View pulls from the model.
"The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes some input action and the active controller notifies the model to change itself accordingly. The model carries out the prescribed operations, possibly changing its state, and broadcasts to its dependents (views and controllers) that it has changed, possibly telling them the nature of the change. Views can then inquire of the model about its new state, and update their display if necessary."[1]
Once you're down with pushing updates, you tend to also see "optimizations" that also push the data to the view (very much what the linked article describes). Again, not MVC, View pulls, model doesn't push.
If the view only refreshes itself and pulls from the model when notified, it's hard to get an entangled dependency graph, and downright impossible to get loops.
So if you get loops, you're definitely not doing MVC.
As to the "multiple sources" feeding into a "myriad of components", that also doesn't quite match. In MVC, all sources feed into the model. When the model changes, it sends its change notification, and it doesn't really matter where the original change came from, the action afterward is the same. So if "multiple sources" are causing you problems, that is a strong indicator that you are not doing MVC, and "myriad of components" also indicates that you don't have a strongly developed model.
[1] https://web.archive.org/web/20100921030808/http://www.itu.dk...