New list of cart items
It’s really good when you start building a structure of components to think
about which is the responsibility for each one in terms of reusability. Differentiate content from containers. Ask yourself:
- Are those items responsible for managing the selection in this list?
- Which is the best place to put a handler for managing the selection?
It’s easy to change your mind and start seeing them from another point of view. Imagine a component SelectableList and CartItem. Let’s check a new approach with this layout:
The differences are subtle, but you will start taking advantage of them.
Components styles
A common pattern to know you are mixing responsibilities between components is if you are abusing of margin CSS rule. Content components should expand as much as possible and should not be aware of the surroundings. Container components are the right ones for managing the space between content components, and you can achieve that with padding CSS rules.
As you can see we moved the margin-bottom rule from the cart item to a padding-bottom rule in selectable-list.
Try to convert component margins to paddings
When you start using this approach you will discover that specs like flexbox fit much better with all your requirements.
Components business logic
One of the most interesting features from DOM and of the most misunderstood is the event bubbling. When you understand how it works and which are the main topics you need to take care of is when you all this new component structure shines.
A brief summary for event bubbling is that an event that happens in a DOM node goes through all the parent nodes until you call stopPropagation method.
Taking this as premise, it’s really easy to share all the responsibilities out
in our application between all the components in it.
If you think about who is the responsible for managing the selection, now the answer is really easy. It must be the SelectableList.
SelectableList:
CartItem:
The really cool thing about this is that now the responsibilities are really
clear, and both components can evolve without clashing between them. Do you want to add multiselection in SelectableList? Go for it. Are you adding new stuff to CartItem? No problem.
In terms of component logic, play with event bubbling to decide how is the owner for each event is generated in the application. If you think an event should not go through upper components, stop it with stopPropagation method.
If you find yourself trying to disable some specific zone in your component, you can take advantage of pointer-events property to have a better control over what is clickable.
Conclusion
You can extrapolate those examples to hundreds of use cases. The result will be a really good set of reusable generic components and a set of easy components linked to your business logic.
With this set of generic components, is easier to apply improvements to accessibility in your application. This will step your application up in terms of quality adding value to many parts of it at once.
Try to think in containers and content every time you are creating new
component and you will be able to figure out the best for you!