Content vs ContainerDecember 2, 2016·7 minutes read·Originally publishedhere
I'm sure that you played this game hundred of times when you were a kid. At that time you learned how to fit a different kind of shapes in their corresponding places. This game is going to be a good metaphor for the next story.
Falling into this bad pattern of mixing responsibilities can impact in many components in your source code not only in your component style but even in your component logic. The main goal is to get better components in terms of reusability. I'm going to use this example to analyze it in terms of:
- Components styling (UI)
- Component business logic (UX)
All the examples presented in this post are based on React classes and JSX markup but those advice apply for whatever technology you use.
List of cart items
An easy example for it could be something like this:
And the stylesheet something like this:
When you start trying to convert this layout in components the first approach that comes to your mind is something like:
CartListcomponent and the
renderCartItemis going to render
linodes with all the required stuff for each item in the list with all the required classes to show all the selected items.
Maybe at that point you don't see the problem but sooner than later you will start facing problems regarding this decision.
A few weeks later, you get new requirements for your cart. Users should be able to multiselect items in this list. You start implementing this feature and you start needing some way to communicate between items to know if they are selected, sending events, toggling classes in the item, etc.
Wait a minute, this is going crazy…
So, the answer for including this behaviour in the item is probably no.
Now, stop for a second and think in terms of containers and content. Which are the container and the content for this layout?
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?
CartItem. Let's check a new approach with this layout:
The differences are subtle, but you will start taking advantage of them.
marginCSS 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
margin-bottomrule from the cart item to a
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.
Taking this as premise, it's really easy to share all the responsibilities out in our application between all the components in it.
SelectableList? Go for it. Are you adding new stuff to
CartItem? No problem.
pointer-eventsproperty to have a better control over what is clickable.
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!