I feel that the MVC pattern and its derivatives (MVVM, MVP, MVW..) is sort of dead. A new pattern is born: The state management pattern (flux, mobx...).
Well, after learning these patterns, it seems that they're not so different, component is VM, state is Model and that's it.
Am I right?
- If Yes, why do we need to rename that entities (store instead of model), IMO it makes it more complicated to understand the new concept, because we (me) search for a big difference which confirms that everything must be renamed...
- If I wrong, please help me understand where are the differences? I mean it must have a huge difference to rename the whole concept...
Thank you
If you consider DOM as View, components/VirtualDOM as ViewModel, store as Model, well, imo it is MVVM. So I think you are not wrong. Actually, in my project, I name my global MobX stores as Store, and name my local MobX stores(that are working for certain components) as Model. (If there are better naming pratice, please tell me)
At the same time, the state management pattern is quite different from MVVM/MVC/MVW.
- Data in Model: You can save user settings like preferred languages or themes in stores, so that your stores are different from traditional
Model, which is supposed to deal with business logic and data.
- Amount of Model: If you use Redux or Hyperapp or sth like them, there is only one global state tree. So it is quite different from traditional ways in which you create a lot of
Model objects.
- Component-Driven: You do not need to handle everything. You can just import a component which is created by others and simply pass data to it. Then it will deal with user interactions and update the view by itself. Maybe it contains a
Controller, maybe it contains a Model, maybe it contains none of them. It doesn't matter. You simply don't care.
- Snapshot: You can take a snapshot of your state and save it as a string. Next time you can just parse the string and restore all the website/system. Just like save/load of an electronic game. This is a principal of the state management pattern. While traditional
MVVM/MVW ways does not force you to do that. (And also I think it is quite difficult for traditional ways to do that, perhaps impossible)
- Immutable: Take React for example, you have a state and a virtual-dom tree, you do not change them, you generate a new state and a new tree to replace the old ones. You should be aware of the life circles of the tree and know how to generate a new tree efficiently. It is obviously different from traditional
MVVM/MVW ways.
So I think it is not a bad idea to name entities like components or stores in a new way. If you name them in old ways, maybe programmers will code in old ways, and as a result they will not enjoy the full power of modern frameworks.