Synopsis:
There are a number of ways within the Lightning Framework to coordinate shared data among multiple Lightning components. When each of the components being synchronized are in their own isolated context separate from the others, custom APPLICATION level events are the only option. But when the components can share the same container, custom COMPONENT level events or using aura:method tags (to expose an API for each of the components) can be used instead. However, these options require writing (and testing and maintaining) javascript to synchronize the components’ shared data. This post offers another alternative; one that requires no javascript, and no custom events, but only markup. Additionally, the technique described can overcome limitations of COMPONENT events as well.
The Details:
Consider the diagram shown below. It depicts a Container component with multiple other components inside. The Nested component itself contains a component, which happens to also be a separate instance of the same Inner component also housed in the main Container.
Each of these components contains a simple text input field, where all of these fields display the same value by using the attribute data binding technique. The markup below generates the components as shown. Notice that each containing component is binding its attribute to the corresponding attribute on the contained component(s). Although all components in this example have named their attribute “data” there is no requirement for it to be so. The attribute names can be completely different, so long as the binding is specified correctly.
Container:
Nested
Inner
After including the Container component within a FlexiPage or within its own App and running it, a change made to any one of the input fields will also be reflected in the other components automatically. All with just some simple markup. Here’s an example after entering text in one field - the magic happens when the field loses focus.
Use Cases:
Top-Down Sharing
Imagine a Container that manages a list of records and maintains a pointer to the current one. Now suppose that each of the contained components interact with the current record in different ways. Through binding the contained components to the current record stored on the Container, whenever the Container points to a different record, all of the contained components bound to that pointer will automatically reflect the change as well, showing the newly-selected record’s data.
Bottom-Up Sharing
Alternatively, consider a Container that is serving as a centralized access point for the activity of the contained components. Whenever any of the contained components effects a change to a bound attribute, the Container is automatically aware of that change. This scenario would likely have attributes bound 1:1 between Container and contained component, but it doesn’t have to be restricted to that.
Peer-to-Peer Sharing
What do you do when you want to share data from one inner component to another? COMPONENT level events can only be handled by the originating component and the outermost component in the hierarchy. You could use an APPLICATION level event, but that’s overkill. Instead, the Container in the above scenario could serve as a bridge between any two components within the Container. In this way, attribute binding enables data sharing between sibling components with zero overhead.
Conclusion:
While attribute data binding isn’t the best technique for all situations, as when the components aren’t within the same container, it can be a great alternative to managing custom COMPONENT level events when all of the components reside in the same context. It even overcomes the limitations of COMPONENT events. Depending upon how you architect your app, this technique can cover a variety of use cases.
If your company or nonprofit is interested in taking your Salesforce org into the Lightning era, contact us:
