Picture from Amazon.com 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. I’m going to go through one example to know how to identify you are mixing responsibilities between components and how to enforce the . When we are going to highlight the figures of what is content and what is a container. single responsibility principle 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 Imagine a list of items in your cart. We have three items in our cart, two of them are selected and one of them is a item. Each item has a button to let the user remove items from the cart. premium 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: This list will be the component and the is goingto render nodes with all the required stuff for each item in the listwith all the required classes to show all the selected items. CartList renderCartItem li 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… If you reuse those items in another place in your application, maybe you don’t want the selection behavior and you start adding more and more conditionals to choose which are the behaviors you want for all the places they are used. Do you want to add the selectable behavior to a list of , but this one is types? Order CartItem So, the answer for including this behavior 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 thinkabout 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 and . Let’s check a new approach with this layout: SelectableList CartItem 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 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 the space between content components, and you can achieve that with CSS rules. margin managing padding As you can see we moved the rule from the cart item to a rule in . margin-bottom padding-bottom selectable-list Try to convert component margins to paddings When you start using this approach you will discover that specs like fit much better with all your requirements. flexbox 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 method. stopPropagation Taking this as premise, it’s really easy to share all the responsibilities outin 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 reallyclear, and both components can evolve without clashing between them. Do you want to add multiselection in ? Go for it. Are you adding new stuff to ? No problem. SelectableList CartItem 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 method. stopPropagation If you find yourself trying to disable some specific zone in your component, you can take advantage of property to have a better control over what is clickable. pointer-events 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 in your application. This will step your application up in terms of quality adding value to many parts of it at once. accessibility Try to think in containers and content every time you are creating newcomponent and you will be able to figure out the best for you! ❤️ If you like this article, please click on the button below and follow this publication so you don’t miss out.
