What's about the Model? about react-model-view-viewmodel HOT 4 CLOSED

Hi,

Thank you for taking the time to write, I really appreciate it. It shows that people are taking an interest in this.

You are correct, this library does not address the Model at all and mostly provides the ViewModel infrastructure for React components, making this rather a library than a framework.

The Model is generally very specific to the domain that the application addresses and there are multiple approaches on how this can happen. From a purely functional one to Domain Driven Design and pure object oriented, it really depends on the application and what it wants to solve. This is the reason I haven't included anything about the Model as it is very difficult to pin what would be something common across all. Even with the ID of an entity, is it a number? Is it a string containing a GUID/UUID? What about composite keys, generally used for many-to-many relationships?

Validation can come in many shapes and forms. The Model should always be in a valid state after any method call (the method itself may update the model allowing it to have intermediary invalid states, but it is all encapsulated inside the method), this can be enforced through validation rules, like you suggested using decorators, or cover for more complex scenarios using a validate method or even a validator depending on how much we want to separate things.

Sometimes it is difficult to run a full validation on the entire model leaving developers to ensure that it is left in a valid state, this means that all inputs that may change the model are validated so that when the changes are applied it is left in a valid state (similar to Model Checking but done manually, this usually happens when there are related entities involved, we don't fully check the related entities and just assume they are valid). This leaves the form implementation to handle all validation which connects the Model and the View through a ViewModel. This is something that ViewModels can do, as opposed to Models, is to have intermediary invalid states and provide error information about that. The error information does not really belong to the Model as it should always be valid, but it makes total sense for a ViewModel.

In my opinion, I think the ViewModel is the most critical part of an MVVM implementation. Any bad Model design will be generally bad with any UI pattern, regardless of how much we try to isolate it we still have to deal with it. A good Model design will work well with any UI pattern leaving the choice of the UI pattern to be the appropriate one for the type of interaction that is desired. Sometimes it's MVVM, other times it's MVC, and on other occasions it's Flux, and others.

In my experience, the quality of an MVVM implementation rests on the quality of ViewModel design. Again, if the Model design is bad, that can leak into ViewModel design as well, but that is generally applicable with any pattern not just MVVM. This is why the accent of this library is on the ViewModel and not the other two parts, the View is handled by React, while the Model is not handled at all as it is very loosely defined to begin with. If you want MVVM, you need a good ViewModel infrastructure that works well with your View layer. The mapping between ViewModels and the Model is handled by the former (load and save methods).

I wouldn't necessarily map a single View to a ViewModel as the same ViewModel can be consumed by multiple Views. For instance, a list of items can be shows as a table, or just as a list. Different Views, same ViewModel. To find the View by the ViewModel is something that should be done outside of the ViewModels themselves and it's something that is part of the View layer. A presenter component or something like that which knows about these mappings and picks the right View for a given ViewModel.

From what I've noticed there are around 3 categories of ViewModels, global ones that are generally scoped to the lifecycle of the application (e.g.: handling notifications), display ones that are just able to load some data and provide it in a way that is easy to present (picking translation keys, tidying up the structure to what is just being presented and not the entire Model, maintaining that structure as the Model changes) and the most complex ones, edit ViewModels.

These are basically form representations, forms that are defined and live outside of the View and presented in one or multiple Views (1 form page, 1 form page with tabs, wizards/multi-step forms). They are not only able to load and provide information in a presentable way, but they also handle validation. In some cases, it's just a range check for numbers or dates, or lengths for text fields, in other cases fields have dependencies between them (the end date cannot be before the start date, or a list of items must have unique names). All of this is done by ViewModels to both define the form (what is editable) and validate it. Once we submit the form, we basically save the changes which in turn update the Model, but only at that point, not a moment before as we always need the Model to be in a valid state. The ViewModel can keep going in and out of valid states, but nothing is really being saved at that point, it's just work in progress.

from react-model-view-viewmodel.

I need a time to answer it. Sorry! I have overloaded those weeks. Anyway,... to be continued... :)

BTW... Some interesting solutions you can in Aurelia framework, which is pure MVVM framework. Anyway, it lacks Model facilities too. I implemented missing VM and M things in my own library @logofx/aurelia-mvvm-plugin
. I'll be very glad, if it's somehow helpful in your case.

from react-model-view-viewmodel.

It's ok, I am glad you did write the comment because I was beginning to wonder if I would hear back from you 🙂

I have heard of Aurelia framework but never looked into it or what it does. At a glance it does look interesting and there can be useful information, thanks!

from react-model-view-viewmodel.

I've added discussions to the repository, they seem really neat and I think the questions you raised are better suited for that space. They are more or less the same, however there is an emphasis on having conversations, I'd like to keep the issue tracker strictly for issues from now on.

I'll be moving this over there.

from react-model-view-viewmodel.