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.
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.
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.
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.
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.
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: