Phase 5: Advanced & Professional Skills

Component library with variants, sizes & accessibility

Advanced ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you’re building a fantastic LEGO city, full of houses, cars, and people. You could try to build every single window, door, and tiny car from scratch, one brick at a time. It would take a super long time, and some of your cars or windows might end up looking a little different each time you build them, even if they're supposed to be the same! It’s really tough to make everything look neat and consistent when you start from tiny pieces every single time.

That's where something really cool called a "component library" comes in. Think of it like a special, organized LEGO box filled with ready-made, perfect little LEGO creations. Instead of building a car from scratch every time, you just grab a finished car from the box. But what if you need different kinds of cars for different jobs? This is where "variants" help. It’s like having a button on a website that says "Buy Now" (which is important!), but you also need one that says "Add to Cart" or "Delete Item." They are all buttons, but they do slightly different things. In our LEGO box, you don't just have one car model. You have different variants of the car: a speedy race car, a sturdy police car, or a big, comfy family car. They all do the job of being a car, but they look and feel a bit different for different purposes.

And what about "sizes"? Well, sometimes your city needs a tiny car for a small street, or a giant truck for a big highway. Instead of guessing how many bricks to use to make a small, medium, or large version of something, our special LEGO box also has different "sizes" of the same creations. So, you can pick a small race car, a medium race car, or a large race car, and they'll all be perfectly shaped and ready to go. You don't have to count studs or worry if it'll fit – you just pick the size you need, and it’s always perfect.

So, when people are building a website or an app, instead of building every tiny button or text box from scratch, they just grab a ready-made "component" from their "component library." They can then say, "I need a button that's a 'primary' variant (meaning it's the main thing people should click) and I need it to be 'large'." This means they can build amazing, consistent, and beautiful websites and apps much faster, without having to worry about every little detail looking just right, because someone already made those perfect LEGO pieces for them!

An advanced component library goes beyond mere reusability; it's the practical implementation of your design system, encapsulating its rules and flexibility. "Variants" allow a single component to express different semantic purposes or visual styles while maintaining its core functionality (e.g., a Button component having primary, secondary, or destructive variants). "Sizes" define pre-approved dimensions for components, ensuring visual consistency across different contexts (e.g., small, medium, large for a TextInput). These properties are typically exposed as component props, directly mapping design tokens and specifications into consumable code, drastically reducing the need for ad-hoc styling and ensuring brand consistency.

Practically, implementing variants and sizes streamlines developer workflows. Instead of manually applying numerous CSS classes or inline styles, developers declaratively specify component appearance via props, like <Button variant="primary" size="large" />. This approach eliminates guesswork, enforces design system adherence, and makes UI development faster and less error-prone. It also ensures that any designer's vision, once translated into the component library, is consistently applied throughout the application, regardless of which team or developer implements it. This level of abstraction promotes a robust, maintainable, and predictable codebase.

Crucially, a truly professional component library builds "accessibility" in from the very beginning, not as an afterthought. This means every variant and size of every component is developed with ARIA attributes, correct semantic HTML, keyboard navigation support (focus management, tab order), and sufficient color contrast baked into its core. By ensuring components are accessible by default, you empower all users, including those relying on assistive technologies, and offload the complex responsibility of meeting WCAG standards from individual feature teams. This integrated approach guarantees a consistently inclusive and usable experience across your entire product suite.

Key Takeaways

  • Variants and sizes enable components to be highly flexible and consistently styled across diverse use cases.
  • They abstract design tokens into declarative component props, simplifying UI development and enforcing design system rules.
  • Reduces manual styling and custom code, leading to faster development and more maintainable applications.
  • Accessibility must be a core, built-in feature of all component variants and sizes, not an addition.
  • A well-designed component library ensures a unified, accessible, and predictable user experience.

Code Example

javascript
Preview

How this code works

This Button component is designed to be a flexible and reusable building block for a design system. Its main job is to provide a consistent way to create buttons that not only look good with different styles and sizes but are also accessible. It centralizes all the logic for button appearance and behavior, ensuring a cohesive user experience across an application.

The component accepts various properties, known as props, to control its appearance and behavior. For instance, variant lets developers specify a style like 'primary' or 'destructive', while size controls dimensions like 'small' or 'large'. Notice that variant and size have default values; a button will always appear 'primary' and 'medium' unless explicitly told otherwise. The component dynamically constructs a className from these props, like "button primary medium", which then triggers specific styles defined in the linked Button.css. Crucially, it enhances accessibility by automatically setting the aria-label attribute. If a custom aria-label isn't provided, it intelligently uses the children text inside the button as the label, but only if children is a simple string, making sure screen readers always have meaningful context. It also passes through standard props like onClick and disabled, along with any other ...props to the underlying HTML button.

Related Articles

Hand-picked reads to go deeper on design systems & component libraries.

Back to Frontend Developer Roadmap