Skip to main content

Thinking in Components

When it comes to components the easy and fast way is to just build the component as we see it. A button, a hero or card component for example. We don't think about reusability because we don't have to. The aim is to deliver fast.

But what if we thought about things differently. What if we saw the bigger picture as not just the application you are creating but the future long term goal.

What if we thought about building components so that they are extendable, theme-able and reusable across different code bases. If we could do that then we would be able to deliver applications at a much faster pace. We would be able to scale much easier.

Components should have a sole responsibility. In other words, a component represents a clear and meaningful functionality. Each component should include the code, styling, unit tests, documentation, and usage examples.

Why Should Teams own Features?#

  • Helps build mastery and allows autonomy
  • Communication via APIs
  • Separation of concerns
  • Build together but stay independent

Why should Components be Reusable?#

  • Reduce duplicated code
  • Easier maintenance
  • Faster development
  • Sharing is caring

Why should Components be Themable?#

  • Easier to reuse
  • One component many options
  • Easily change branding
  • Support multiple themes: dark / light / high-contrast / multiple brands

How do we discover Components?#

  • Sharing components to the cloud
  • Naming our components correctly
  • Organizing our components
  • Labeling our components

How do we improve consumer’s dev experience?#

  • Thinking about how the component will be used
  • Documenting our components
  • Creating compositions
  • Tests as a documentation feature
  • Live component playground

How should we reuse Components?#

  • Think about components as services
  • Integrate components together to form concrete components
  • Share those concrete components for other teams
  • By not reinventing the wheel

How do we trust our Components?#

  • By creating tests
  • Making the tests easily available
  • Simulations
  • Dependent testing

How do we think about Component Composition?#

  • Props
  • State
  • Route
  • Styling

Why should we think in Components?#

  • To build scalable products
  • Reuse components across various projects
  • Deliver faster in the long term
  • Because we want to develop in Harmony