You can have one (versioned) model repository used by all tiers of your app. No philosophical essays can be considered as apology for breaking the most important design pattern of JS: developers must respect the standards (and the code culture of the company). We should resist the temptation of rogue paths. You execute the same validation rules on the UI and in the REST services you use the same models in the MVC mapping code and DB services. To have a real JS-based full-stack solution, the need of shared data models and validation comes naturally. PUG is a very simple, yet power templating engine to be used. Styles, layouts, UI components could be refined over the time not inducing any process on service-level. The view layer must be freed from unnecessary technical decoration within the reach of everyone during the whole lifecycle of the app. Some environment involving multiple teams urges the need of an independent view layer, where the functional and the presentation layer can be distinguished. This solution wants to show a proven way. In other words, you should be encouraged to choose the template engine and the orchestration structure of yours, fitting the best your project. To support the "multi-island scenario", you can associate multiple views to the same model or mount the same templates to different DOM parent as your needs encourage you to orchestrate.Īpplications are not created in a vacuum, teams are working on it and design and code are evolving continuously urging the development team to handle representation freely. models and validation rules with plain JS objectĪnd pug-mithrilier will generate the necessary Mithril components you can mount to your app.The aim is to have a toolset facilitating a design-focused orchestration leveling a very simple way to manage the MVC part of a webapp. Pug-mithrilier is a small utility library allowing you define your views in PUG templating engine.
PUG-MITHRILIER - A design-focused abstraction layer over Mithril and PUG.
0 kommentar(er)
