5 ms·

All these acronyms don't matter. What matters is how the architecture deals with shared mutable state and whether or not it allows for UI functionality to be ea

All these acronyms don't matter. What matters is how the architecture deals with shared mutable state and whether or not it allows for UI functionality to be easily composed without turning app state into an incomprehensible, incoherent mess. MMVM sounds like a mutable inheritance based architecture. Would love to dig deeper, but here is "how I feel" https://evolvingtrends.wordpress.com/2015/12/03/why-react-native-is-a-huge-deal/ https://evolvingtrends.wordpress.com/2015/12/03/why-react-na...

Aleman360 11y ago
UI apps have all sorts of unavoidable copied state. For example, your data base might have separate fields for first name and last name, but your UI might concatenate these strings into a single one. Whether that's stored in a ViewModel or DOM is not a practical difference. There's nothing about MVVM that says you have to copy Model state in your ViewModel either.
- idibidiart 11y ago
  That's why UI architecture (at least on the web) has been moving toward an architecture where you have a single app state store and a unidirectional flow of app state mutations (e.g. in Flux terms: from Action to Store and Store back to View but not the other way around) If you make the app state store immutable then you land in the sane model of having app state transitions (e.g. Redux) where you can have time travel thru app state, which is awesome and aids in debugging. The REST layer decouples server and client states, so we're just concerned with UI state here. Local state isn't avoidable I agree but should be reserved for things like animations that are outside the app state model (unless we're talking about interruptible, resumable, rewindable animations) ... Again, roughly speaking, but love to dig deeper.
  - Aleman360 11y ago
    That's generally what you try to do in MVVM apps too... you have some "service" that stores all the state. User input goes: View -> ViewModel -> Service and the data goes Service -> ViewModel -> View However, the same app state may be presented in different ways in different parts of the UI. Those different ways could each have their own ViewModel for transforming that state as needed for its presentation. Poorly architected MVVM apps have lots of inter-ViewModel dependencies... that's where you wind up with state spaghetti.
fleitz 11y ago
Yup, don't do shared mutable state. It is the enemy. Avoid it like the plague. I really love value semantics with structs in swift, it's almost always the right thing, and generally very clear when it isn't. If anyone ever programmed so that int a = 15 int b = a b = 17 assert(a == 17) meant that a was now 17 they'd call it insane, I have no idea why anyone would want that as the default behavior.
- Retra 11y ago
  If you had a language where that were the default behavior, it would not be insane at all (e.g., see all of mathematics,) and you probably wouldn't be able to even compile it the way you've written. You've set b equal to two different values.
  - fleitz 11y ago
    My point exactly.

Aleman360 11y ago

UI apps have all sorts of unavoidable copied state. For example, your data base might have separate fields for first name and last name, but your UI might concatenate these strings into a single one. Whether that's stored in a ViewModel or DOM is not a practical difference. There's nothing about MVVM that says you have to copy Model state in your ViewModel either.

idibidiart 11y ago
That's why UI architecture (at least on the web) has been moving toward an architecture where you have a single app state store and a unidirectional flow of app state mutations (e.g. in Flux terms: from Action to Store and Store back to View but not the other way around) If you make the app state store immutable then you land in the sane model of having app state transitions (e.g. Redux) where you can have time travel thru app state, which is awesome and aids in debugging. The REST layer decouples server and client states, so we're just concerned with UI state here. Local state isn't avoidable I agree but should be reserved for things like animations that are outside the app state model (unless we're talking about interruptible, resumable, rewindable animations) ... Again, roughly speaking, but love to dig deeper.
- Aleman360 11y ago
  That's generally what you try to do in MVVM apps too... you have some "service" that stores all the state. User input goes: View -> ViewModel -> Service and the data goes Service -> ViewModel -> View However, the same app state may be presented in different ways in different parts of the UI. Those different ways could each have their own ViewModel for transforming that state as needed for its presentation. Poorly architected MVVM apps have lots of inter-ViewModel dependencies... that's where you wind up with state spaghetti.

fleitz 11y ago

Yup, don't do shared mutable state. It is the enemy. Avoid it like the plague. I really love value semantics with structs in swift, it's almost always the right thing, and generally very clear when it isn't. If anyone ever programmed so that int a = 15 int b = a b = 17 assert(a == 17) meant that a was now 17 they'd call it insane, I have no idea why anyone would want that as the default behavior.

Retra 11y ago
If you had a language where that were the default behavior, it would not be insane at all (e.g., see all of mathematics,) and you probably wouldn't be able to even compile it the way you've written. You've set b equal to two different values.
- fleitz 11y ago
  My point exactly.