Advanced Model Binding
Components often observe and modify the state of other components. Consider the following example:
The scale bar component displays information about a particular map. More specifically, it is dependent on the data of a map model to display its values.
Components express this data dependency in the form of models that are marked as "imported" or "exported". If we know that the scale bar "imports" a particular type of model, and that the map "exports" the same type of model, we can resolve those dependencies simply by plugging exported models into the components that import them.
When the system places the scale bar into the layout, it will attempt to satisfy any model imports declared by the component. By default, this happens by walking up the tree from the location of the component being slotted and simply finding the first ancestor that exports a model with the matching type, like in the basic example above.
However, in the following example with two scale bars, how does each scale bar know which map model it corresponds to? Both are placed outside of a <map> component, and there are two possible map models to bind to.
We can explicitly bind each scale bar to the appropriate map with the models attribute. The models attribute will tell a component to look for an exported model on the component matched by the expression. In this example, the models attributes are looking for components with the id map-a and map-b respectively.
Nested Model Imports
In previous layout examples, layouts were shown where components related to a map, such as zoom buttons, were nested within a map. It was assumed that the component would bind to the map it was placed in, but why?
Certain components, such as <zoom/> or <geolocate/>, require a Map Model to function. To locate a Map Model, the layout tree hierarchy will be searched upwards, starting at the requesting component. When a element in the layout is found that provides the required model, (in this case, the <map/> component provides a Map Model), the requesting component will import the model. If the correct model is not found on an upwards search, a breadth first search will be performed from the root of the layout tree.
Take this more complicated layout for example.
This layout has a <search> component which requires the context of a specific map to function. However, this component is not nested within the <map/> component in the app. Therefore, it will start a breadth first search from the root of the layout to discover a map model and import it.
The models Attribute
Sometimes, you can have multiple components that need to bind to the same model.
To simplify this binding, we can take advantage of the default behavior of searching up the layout tree for the appropriate model and bind the map to the parent panel of the components which need to reference a map model.