A Guide to Building, Understanding, and Benefiting from Component Libraries for Advanced Organizational Efficiency

Intro

As your organization grows, your development teams building new features and applications may increasingly struggle with code duplication. Duplication can be combated with components-based engineering, a common practice that encourages the DRY (Do not Repeat Yourself) principle. Building a complex application using components as building blocks allows each unit to be used in different contexts. This approach is in contrast to older methodologies of building user interfaces with inheritance, which can be brittle when misused.

Benefits

Using components can help your organization achieve several feats:

Interoperability

Well-designed and tested components can be incorporated into any project that uses the same (or compatible) framework without failure.

Scalability

Components can be leveraged to prototype and develop new applications rapidly. Changes made to an individual component can immediately propagate to every application that consumes it.

Consistency

The development lifecycle of components is standardized. Components are designed, developed, and tested in isolation. In addition, your users have a consistent experience across each application.

What is a Component Library?

A component library is a package from which any application can pull components. The library can be published and imported as a unit, or components can be published and versioned independently.

When Should You Use a Component Library?

• Your applications are all built with a common UI library or framework, like React or Angular.
• You want to ensure a consistent experience across multiple platforms.
• In the case of a mobile application, you are using a tool like React Native to ensure your components can run on any device.
• The entire team, including developers, designers, and leadership, is on board with using and maintaining using the component library.

When Shouldn’t You Use a Component Library?

• Your company has distinct product teams for each of your app’s targets, e.g., separate Web/iOS/Android teams using native UI/UX patterns for an OS-specific feel.
• Your company or team does not have the bandwidth or resources to maintain the library.

Building Your First Component Library

• Choose the target platform or framework

  • For example, if your organization has decided to use Angular, the component library should contain only Angular components or directives.

• Develop and stick to conventions.

  • If you are using a tool like React Native for Web to do cross-platform development, ensure all components in the component library function properly on both web and native environments. Components that will never have cross-platform support should be located in a separate library.

• Choose which tools your team will use to build the component library

  • Storybook: Storybook is an open source JavaScript tool that can be used to develop, test, and document components written using React, Vue, Angular, and many other UI frameworks.
  • Lerna: Lerna is a tool used for managing projects that will be published as multiple packages from a single repository. It allows you to version each package or component independently of the others.

• Organize your components based on complexity

  • Most components should be purely presentational ones, i.e., components that are unaware of the context they are used in. For example, a simple dropdown should not be aware that it displays a list of customers, but it should be able to be configured to perform that role.

• Organize your components based on context

  • Some components may be more complex and have expectations about the context they are used in, e.g., they hook into specific application state. These components can belong in a component library, but they should be separated from the purely presentational ones.

• Use your own building blocks

  • When building new, more complex components, reuse existing components as much as possible to prevent code duplication and allow your library to scale effectively.

• Make components independently configurable

  • Every component should take a wide selection of options that allow it to be configured extensively.
  • Every component should have style hooks to override default styles.

• Make components globally configurable. Your component library should ship with a method for global configuration that adds support for global theming, timeout configuration, etc.

• Create a publishing strategy

  • Version components independently. Lerna provides a fixed version mode, but avoid it if multiple applications will ever use your components. Fixed mode is useful when publishing libraries and tools (e.g., Angular or Babel) where each package relies on a core library or packages rely on each other to be at a specific version, which typically isn’t the case in a component library.
  • A tool like Lerna or Bit is critical when versioning and publishing components independently.
  • Use conventional commits to generate changelogs and version numbers automatically.
  • Deploy and share interactive documentation using a service such as Bit or host your Storybook as a static asset.

• Testing

  • Storybook and Jest both have solutions for conducting automated visual testing to ensure that no unintended visual changes are made to your components.
  • https://storybook.js.org/docs/testing/automated-visual-testing/

Extracting Components from Existing Code

Every component in your library won’t be built from scratch. You might have existing code in an application that could be isolated and pulled into a component library. Here are a few guidelines to help with that process.

• Start at the “leaves” of your application.

  • Presentational components are the backbone of a user interface. Start at the most simple pieces of UI that could be used in any context, e.g., text elements, buttons, headings, list items, etc.

• Move to the more complex components.

  • Use the leaves you have established to build more complex components. Ideally, complex components should be mostly comprised of purely presentational components.
  • Finally, decide if the even higher level components are reusable, and makes sense to centralize. Examples of these types of components include:
  • A login form that hooks into a standard authentication workflow.
  • A notification component that displays error messages from a logging service used across your entire organization.

Thanks to Levvelers John Mitchell and Brenda Jiminez for contributing to this content.

About Levvel

Levvel helps clients transform their business with strategic consulting and technical execution services. We work with your IT organization, product groups, and innovation teams to design and deliver on your technical priorities.

Our Engineering team is made up of technology agnostic enthusiasts with a wide array of knowledge in popular modern and legacy languages such as Java, .NET, Ruby on Rails, Node.js & JavaScript, Python, and PHP.

We firmly believe that mentoring can be integrated with delivery. Our main focus is on saving our partners as much as possible on the lifetime-total-cost of ownership and maintainability of their systems. For more information, contact us at hello@levvel.io.