I have a set of Lightning Components that I want to allow customers to assemble in different layouts and combinations inside the Lightning App Builder. These components interact: when a user clicks on a button in one component I need another component to react. But they do not contain each other.
This question has already been asked in Lightning Events in Lightning Page Context, but the suggested use of application events isn’t working for me. Yes, firing and handling application events works fine when there is a single instance on the screen, but when there is more than one instance (e.g. console navigation is used), all instances respond to an event from any instance.
This screen shot illustrates the situation: there are multiple instances of the same Lightning App Builder page (IN-17-000299, IN-17-000298, IN-17-000297) on the screen at once and they each respond to each others events which is not what I want:
Is there a way to limit the scope of an application event in this Lightning App Builder context? Is there a pattern I can implement to separate out the events? Is there a better way to get the components to interact?
(This answer suggests an approach where the application event propagation is stopped at the container, but in this case I don’t have control over the container.)
Application-level events certainly are what Salesforce recommends for the use case of components that will be “App Builder siblings” and need to talk to one another.
I think you won’t be able to limit which components see the event, but you can limit which ones respond to it. If I understand correctly your “pitcher” and “receiver” are independent components you expect an end-user to be able to put on a page together and talk to one another.
For the use case where the admin has put multiple groups on the same page, maybe you could put a string identifier field on the component (call it a name, channel, key, what have you) and expose it to App Builder via Design. Then you would instruct admins, if there will be more than one interacting pair, please fill in the identifiers in matching pairs/groups so it knows who’s who. In terms of implementation, every event you fire could include the identifier as an attribute so you can check for it.
For the console use case, you could include
lightning:workspaceAPI in the components. On init, use
getEnclosingTabId() and hold onto that (returns
false if not in console tab). When firing an event, pass a “tab ID” attribute. When catching it, verify both the tab ID and the other identifier match.
If you find any other use cases not covered by these, then just consider, is there something unique that you can use (or provide) to determine whether an instance is the wrong recipient?