We explore a final pattern for inter-component communication.
This article is part of the series starting with Exploring Salesforce Lightning Web Components: Part 1.
While we have explored solutions for communications between Lightning Web Components from parent to child and visa-versa, we need to explore approaches for other situations, e.g., between sibling components.
To communicate between components that aren’t in the same DOM tree, use a singleton library that follows the publish-subscribe pattern.
— Salesforce — Communicate Between Components
First let us remind ourselves of the singleton pattern. In an earlier article, we created a Lightning Web Component; common, that simply exported two functions.
and used them in the HelloWorld component:
As instantiated in a Salesforce page:
- When pressing the Increment button, we see numbers on the console (Chrome Developer Tools), e.g, 1, 2, 3…
- When pressing the Increment button in either component , we see contiguous numbers on the console, e.g., 1,2, 3…
To carry this experiment further, we create a second component, HelloWorld2, that is essentially identical to HelloWorld and instantiate it in Salesforce.
- As before, when pressing the Increment button in either component , we see contiguous numbers on the console, e.g., 1,2, 3…
Next, we create a new Salesforce page, ExamplePage, and instantiate HelloWorld there.
- Even as we navigate between pages in the Salesforce Sales application, when pressing the Increment button in any of the components , we see contiguous numbers on the console, e.g., 1,2, 3…
Finally, we change to the Salesforce Service application:
- In this case, we see the browser reload the page and thus reset the state of the common.js module; i.e., numbers restart at 1
Salesforce Pub-Sub Example
While we demonstrated the singleton pattern (lives across a single Salesforce application), we need to also implement the pub-sub pattern to enable inter-component communication, i.e., a component can publish events and components that subscribe to such events are notified.
Salesforce provides such a pub-sub solution in their Lightning Web Components Recipes repository. With this we can create an example where we have two child components of HelloWorld: Child1 and Child2. Pressing the One button (in Child1) emits an event named one; similarly pressing Two emits an event named two. Both components subscribe to the events named one and two; updating the text (left of the button) as appropriate. Here we see that we have pressed the One button.
We create the Child1 and Child2 components as follows; the only difference is Child2’s value defaults to two and it fires events named two.
- This component uses the @wire decorator to “wire-in” Salesforce data to the pageRef property; in this case, details about the page that is loaded
- Notice that we pass in a reference to the component itself to registerListerner; looking under the hood, this is imply to obtain the pageRef value
- Likewise, notice that we pass in the pageRef to fireEvent
- Looking under the hood, this solution validates that component have the same pageRef value before allowing events to pass between them; meaning components need to be on the same page
We use the Child1 and Child2 components in the HelloWorld component:
Interestingly, this solution means that components cannot communicate across Salesforce pages, e.g., between Home and ExamplePage:
- The first reason that communication does not happen across pages is that the pubsub component purposefully limits passing events between them (using pageRef)
- The second, and more important, reason is that the pubsub solution only passes events; it, specifically, does not support the concept of a global state
In the next article, Exploring Salesforce Lightning Web Components: Part 8, we explore a solution that combines the singleton, pub sub, and global state patterns.