Frontmatter
| number | 1749 |
| title | model.Component: support for dialogs to access the parent model chain as well as multi window apps |
| author | tobiu |
| category | Ideas |
| createdAt | Apr 10, 2021, 4:39 PM |
| updatedAt | Jan 6, 2023, 2:05 AM |
| closed | Open |
| closedAt | |
| routingDispositionSchemaVersion | discussion-routing-disposition.v1 |
| routingDisposition | undetermined |
| routingDispositionReason | no-authoritative-lifecycle-marker |
| routingDispositionEvidence | [] |
| contentTrust | |
| projected | |
| quarantined | 0 |
| signals | [] |
model.Component: support for dialogs to access the parent model chain as well as multi window apps
For more background infos, please take a look at the latest blog post: "Introducing view models for the neo.mjs Javascript UI framework"
The 1.5.4 has already extended view models with adding stores into the mix: https://github.com/neomjs/neo/releases/tag/1.5.4
More input on the dialog example.
What you can do right now, assuming you create the "add customer" dialog inside your customer view controller:
createAddCustomerDialog() {
this.addCustomerDialog = Neo.create({
// configs
listeners: {
addCustomersFormSubmit: this.onAddCustomersFormSubmit
}
});
}
Once the dialogs form is filled out and a user hits the "submit" button, you can fire a custom event, e.g. addCustomersFormSubmit and pass the data to the customers view controller.
This works fine for non complex dialogs, but in case a dialog contains many views & logic it can be limiting (and moving too much logic into a view controller where it does not really fit in).
Torsten (@Dinkh) had the idea to add a parent config (reference) to vcs & vms.
I got to admit that this one is growing on me.
You could change the value inside your class & instance definitions:
createAddCustomerDialog() {
this.addCustomerDialog = Neo.create({
// configs
model: {
// model configs
parent: this.getModel()
}
});
}
For this approach, parentId needs to get an afterSet methods => parentId_.
This method should fire a change event which vcs & vms need to subscribe to.
When dynamically moving a component inside your apps component tree, the parent references can update their values.
One benefit of this approach: accessing the parent chain is a bit faster. Not really a bottleneck, but still nice.
the new parent logic resolves this discussion.
i will create a new example app to show it in action.
component.getModel()will return the closest view model inside the parent component tree.To do this, we are accessing the
component.parentIdconfig. This config is also getting used for isolatedrender()calls. While the config stores a component id most of the time, it could as well contain a DOM id for top level components.The parent id for a viewport is "document.body" by default, but you can as well render your apps into existing nodes of a not necessarily created by neo DOM structure (e.g. using a component like a web component inside a website / app).
For dialogs, the parentId config matches "document.body" by default as well, since most dialogs are supposed to be a floating overlay, not limiting drag&drop inside a parent container.
However, most dialogs do have a "logical root".
Example: You create an admin module. Your customers view has its own view model and view controller. Now the customers view controller creates a "add customer" dialog. It would be nice if this dialog could access the customers view model (as well as the parent model chain).
From a technical perspective, we need a new component config to make this happen.
E.g.
contextParentIdorcontextParentComponentId(open for naming suggestions!)This config should default to the parentId config, but you can assign different values inside your class or instance definitions.
The second use case are multi window apps. Imagine two browser windows, each containing a MainContainer (Viewport). In case one of these two apps is supposed to be the "main" app, the MainContainer of the "child" app could use
contextParentIdto point to the MainContainer of the "main" app.The result is that both apps share a top level view model (data & stores), which can be helpful for multi window state management.
What are your thoughts on this one?
Best regards, Tobias