When building a web component, designing the component itself should start with examining considerations for its design, security, and accessibility. Considerations can vary based on what the component's eventual purpose, but common goals for web components include easy access and reusability. As such, major considerations could be the different properties a component might have, as well as the states the component can maintain and how much customization can be applied to it.
In my case, I'm currently working with my team to design an infographic card. The ultimate goal is for this to be a web component that can be modified based on a user's requirements, but maintains a fairly consistent layout and structure. The card will have a colored banner that includes an icon, title, and sub-title, as well as a content box beneath it to hold text. Major considerations for this card include how the card will resize based on different information inputted by a user, as well as what properties must be modified to ensure someone can customize the card to their specific use case.
Atomic Design
To ensure this card is reusable at every level, my team and I intend to utilize the principles of atomic design. This will allow us to break our larger card up into smaller components, which will then be combined to create a cohesive product. The following will be smaller “atoms” which will eventually become our molecule: a functioning card.
- The icon
- The banner (includes the icon, header text, and sub-header text)
- The skeleton of the card (a card that contains header and content sections)
- The complete card (a composition of the above atoms)
Difficulties
While atomic design is likely to help our team build this card efficiently and pay closer attention to the necessary requirements and considerations, there are nearly guaranteed to be bumps in the road. Responsive resize within a fixed area can be fairly difficult, and a major use case we'll be trying to account for is someone placing a multi-line title in the banner. Taking the time to design elegant adjustments to our banner component should, hopefully, result in a better card all-around.
Another consideration I had not immediately thought of is security. Even though we aren't accessing any user data or providing any sensitive data, the SVG (small vector graphic) format we'll be using for our card's icon is a known attack vector for embedded JavaScript attacks. As such, we need to make sure that a bad actor cannot misuse a valuable component of our card to harm users who interact with our product. This could reflect poorly on us and those using our component, not to mention the person whose information is made vulnerable by such an attack.
Lessons Learned
Having already built a web component, a button, I feel our team is coming into this project with a clearer understanding of how to interact with and build web components. The structure of LitElement was previously foreign to us, so our first project allowed us to strengthen our knowledge of how Lit works. In addition, I got much more comfortable with CSS during the first assignment. As our team made a circular button that responsively resizes based on its content, I was dealing with CSS I had never touched before. This ultimately pushed me to learn enough to maybe be dangerous, so I'm looking forward to taking those lessons with me into working on this card.