We explore using components together.
This article is part of the series starting with Exploring Salesforce Lightning Web Components: Part 1.
So far we have been exploring Salesforce Lightning Web Components in isolation; now we explore how to compose them to abstract away complexity.
In a previous example, when we were exploring iteration, we had a component that provided the markup for both the list of contacts as well as the individual contacts.
- In a similar way to the @track reactive data binding decorator, the @api decorator creates a reactive data binding where changes are driven from code outside of the component (we will see this in action below)
- Notice that instead of accepting a complex contact object, the contact component accepts two primitives (string): name and title. This is a LWC recommended practice that matches up against similar practices with other frameworks such as React. The primary benefit of this approach is to decouple the component from code outside of the component
We now update the HelloWorld components HTML to use the contact component:
- Notice that the contact component is used in the markup as c-contact. In a more complex example, say a component that is named myComponent, it would be referenced as c-my-component (camel case is converted to dash-delimited)
In the previous example, the @api decorator was used to create a one-way data-binding between the HelloWorld to the Contact components; information flows down the component tree.
How do we move information up the component tree? The answer is events.
In the following example we will create two components HelloWorld (manages the counter value) and Counter (manages the view). Pressing the - and + buttons decrement and increment the counter value by one.
- Passing the value primitive is as in the previous example
- The ondecrement and onincrement attributes are examples of a special syntax, onXXXXXXX, that enable the parent component to listen to DOM events (in this case CustomEvents) from the child component. In this case listening for events named decrement and increment
- In more complex examples, the events can carry a payload; thus the moving of information up the component tree
- By default custom events do not bubble up the DOM tree; one has to directly listen to events emitted by a DOM element. At the same time, custom events (and thus LWC), can be enabled to support event bubbling
note: It is LWC best practice to avoid relying on event bubbling for more complex inter-component communication; for this, we will later explore using global state.
In the next article, Exploring Salesforce Lightning Web Components: Part 6, we explore some more advanced component composition patterns.