Working with shared UI components

As companies get bigger, duplication of work becomes a big problem. One common approach to offset duplicated work is to share code wherever possible.

Sharing code at certain levels of the stack can be difficult. On the back end it’s common to share things like Docker images or web servers. On the front end we often start off by building reusable UI components.

The basic concept is pretty straightforward. Let’s start with something familiar like the Facebook “like” button.

Most companies value consistent branding company-wide. Facebook likely only wants one version of their like button in production at any time. This is a great reason to enforce all teams at Facebook to make use of a single, reusable component.

There are a lot of advantages to this approach:

The problems arise when it comes to implementation.

Most of the companies I’ve worked for have been framework agnostic when it comes to front end tooling. They don’t mandate consistency and so they end up with a lot of teams building a lot of components on a lot of different stacks. I have a strong suspicion this is the case for the majority of companies out there.

This poses two main problems: state and bundling.

Unfortunately, modern UI components are more than CSS and HTML. They contain their own state. You’ll have to decide how product applications should interact with shared components.

You have a few options:

A good approach here is to make what some people call “controlled components”. These are components that optionally take in properties but default to managing their own state. For our like button example, we can optionally give it a userId and a pageId but ideally it will have some basic functionality even if neither are passed in.

This gets tough if shared components use the same loaders but with different options. At my current job we have a custom wrapper around webpack to account for this. But it can be quite a hassle.

It’s worth noting that even if you use all the same loaders and file extensions, failing to stay consistent with versions of those loaders can cause the exact same fragmentation.

Shared components are great and will help you cut back on code duplication. I’d say it’s best to go in with a game plan for how you’ll handle state and bundling.

My recommendation is approach #2 from the state options above. Make explicit APIs for each shared component so it gets the data it needs to be able to manage state by itself.

As for bundling I’d recommend either mandating a set of tools (CSS, view layer, state management). If you can’t do that, at least stick with your bundlers defaults for each file extension!

Related posts:

A poetic writing piece on emotional and habitual patterning and how to grow from the limitations of them.

Astrology is a complex system of divination that has been in practice for centuries. The study of planetary movements and their influence on human life is a fascinating subject that has captivated…

The fundamental question we need to ask ourselves is why is it, we want to write. Because it will be this mindset that determines whether we are successful, or what it is we define success to be…