5 ms·

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

by m90 8y ago

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-dom/ https://www.futurice.com/blog/reactive-mvc-and-the-virtual-d...

mpweiher 8y ago
As usual, that article gets MVC wrong. 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. ¯\_(ツ)_/¯
- RobertRoberts 8y ago
  How would you compare React to Vue in regards to the linked article? I have not used React, but in Vue I have never run into things like "setState, forceUpdate, setProps, render". 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.
- aikah 8y ago
  Don't know why you are getting downvoted, MVC is the combination of the observer and strategy patterns, no more, no less. 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.
- ricardobeat 8y ago
  The problems lie in the way change notifications are managed. Any reasonably complex client application will have multiple data sources feeding into a myriad of components, with a very entangled dependency graph. In MVC, you’ll start sharing models and notifying changes selectively, with a lot of “action at a distance” from component interactions triggering updates. This is usually hard to visualize and debug (worst case, recursive update loops). 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).
  - mpweiher 8y ago
    > Any reasonably complex client application will > 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.
    - ricardobeat 8y ago
      You're gonna have to provide a bit more context for that. What part of the MVC pattern?
      - mpweiher 8y ago
        Various parts. First, the M->V communication should only notify, the View decides if and when to refresh itself, and the action it takes is only to refresh itself. "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/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf https://web.archive.org/web/20100921030808/http://www.itu.dk...

by m90 8y ago

mpweiher 8y ago

As usual, that article gets MVC wrong. 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. ¯\_(ツ)_/¯

RobertRoberts 8y ago
How would you compare React to Vue in regards to the linked article? I have not used React, but in Vue I have never run into things like "setState, forceUpdate, setProps, render". 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.
aikah 8y ago
Don't know why you are getting downvoted, MVC is the combination of the observer and strategy patterns, no more, no less. 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.
ricardobeat 8y ago
The problems lie in the way change notifications are managed. Any reasonably complex client application will have multiple data sources feeding into a myriad of components, with a very entangled dependency graph. In MVC, you’ll start sharing models and notifying changes selectively, with a lot of “action at a distance” from component interactions triggering updates. This is usually hard to visualize and debug (worst case, recursive update loops). 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).
- mpweiher 8y ago
  > Any reasonably complex client application will > 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.
  - ricardobeat 8y ago
    You're gonna have to provide a bit more context for that. What part of the MVC pattern?
    - mpweiher 8y ago
      Various parts. First, the M->V communication should only notify, the View decides if and when to refresh itself, and the action it takes is only to refresh itself. "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/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf https://web.archive.org/web/20100921030808/http://www.itu.dk...