...
Reasons to bother | What changes | Benefits |
---|
- Way too many interfaces where a mere class would do (see IoC part as well)
- The way we used it before is cumbersome and not too beneficial.
- Concept of Model is not well defined.
- Poor component isolation patterns
- views know about sub-views, presenters know about sub-presenters [...and sub-views].
- poor state management (the parent views/presenters may just have most of the child view's state/business logic).
| - We try to prefer classes over the interfaces. If we introduce interfaces, we try to keep them small and function-oriented.
- Instead of MVP we use something like MVVMP (Model-View-ViewModel-Presenter)
- Model is the good ol' datasource like JCR workspace.
- View is now the entry point and the driver of the pattern. Views may compose and even interact with each other (though we we should not encourage that!)
- ViewModel is the state of the View (all the properties that define the view in real time)
- Presenter - optional, completely isolated part which is used to help View interact with Model/ViewModel
- We implement the ViewModel part via so called
ViewContexts - interfaces that describe a certain part of mutable state (selection, value, location etc).- We provide the views with the ability to bind contexts and share them with the sub-views (see more in the IoC section).
- For the ease of use, we do not enforce the developer to actually implement the interfaces, we generate them. We use some reactive technology for convenient subscription.
| - Views are more component-like and are easier to compose.
- Interfaces/classes do not expose methods like
#refresh() , that encourage external control over the view. - All the internal view state management happens in the view itself (no case when sub-app reacts on events and updates the state of the sub-views/components).
- All the necessary context can be injected via
ViewContexts
- Some synergy with how client-side frameworks manage the UI's (Redux/React contexts do similar things though in more conventional way)
- Less code to write (less noisy listener interfaces, less abstractions)
|
As an example of benefits we get after applying the new concepts, let's take a look at the class diagram of the Browser sub-app before and after.
Before
Image Added
After
Image Added
Inversion of control (IoC) capabilities in UI
...