Think about your favorite retailer’s e-commerce platform. There’s a lot of complexity in that application: the product catalog, the cart module, the checkout page, the review system, the shipping tracking page, and so on. Each component of the web application has a distinct set of features, but they all connect in some way. The cart module is tied to the checkout page, and the product catalog is tied to the review system. So, how do e-commerce sites manage this complexity in their frontend applications?

Composability and modularity are appealing design principles for engineering systems. When employed properly, they can supercharge the development process and ease the maintenance burden of software. But they can be rather difficult to implement, especially as systems age and new business requirements are introduced. While these principles are often considered in the design of backend components, they’re equally relevant in the frontend.

With the growing intricacy of user experiences in different clients and an increasing set of frontend technologies, modern frontend engineering is a complex and sophisticated landscape. As clients do more heavy lifting in web applications and more state is stored on the client side, state machines increasingly manage more and more scenarios, such as the contents and status of a registration form. Furthermore, web applications need to support a variety of targets across mobile and desktop. With great complexity come great bugs and even greater maintenance burdens—but there’s a solution for this.

To build scalable and maintainable frontend systems, we need a strategy for managing and organizing the complexity that exists in the user interface. Scalable and maintainable systems are easier to test, reduce the cost associated with adding new features to an application, and make it easier to upgrade and change certain parts of the UI without degrading the experience for others. Thankfully, a growing number of technologies, such as React, Redux, Vue, and more, are making it easier for engineers to build frontend systems that can scale to meet their needs. But frameworks alone won’t solve these problems. We also need to bring the principles of composable design to the frontend.

The how

The UI

Now, this is all fine and dandy, but how do you actually get it done? There are several fundamental elements to a frontend application to which we can introduce modularity and composability, including styling, event management, and DOM management.

For the purpose of this article, we won’t be prescriptive about what a component is; it could, for instance, be a React component, an Angular view, or a Vue component. We’ll focus on general principles that can apply to any rendering or UI library.

Let’s start off by covering something universal to all rendering libraries: styling. Styling frontends with CSS can quickly become a gnarly affair. Often, the styles applied to HTML depend largely on the structure of the page. In the example below, the nav element is aware of its position on the page and has a child button that’s aware of its inner content. This pattern doesn’t lend itself to modularity or style reuse.

<nav class='side-panel'>
  <button id='settings'>Settings</button>
</nav>

nav.side-panel {
	background-color: green;
}

button {
	color: white;
}

button#settings {
	font-family: Arial;
}

An alternative approach is to implement styles based on the intended effect in isolation and then compose styles by applying several effects on the same element, as opposed to within the context of an existing UI layout.

<nav class='green-bg'>
  <button class='white-fg arial-font'>Settings</button>
</nav>

.green-bg {
	background-color: green;
}

.white-fg {
	color: white;
}

.arial-font {
	font-family: Arial;
}

This pattern might ring a bell. It’s implemented by popular styling frameworks like Bootstrap and Foundation because they’re designed to be used across different frontend implementations.

In addition to avoiding context-dependent styles, composable CSS patterns avoid applying styles to tag-based selectors.

h1, h2 {
	font-family: Arial;
}

The first of the three previous patterns is a global-level style that modifies all UI components within a page, as opposed to the approach in the second code snippet, which can be applied selectively.

Modularity requires subcomponents within a system to be easy to swap out or assemble in sequence. To do this, a composable frontend system should rely on native and standardized APIs, when possible. This makes the frontend system resistant to breaking changes in third-party APIs for fundamental logic such as manipulating the DOM: for example, relying on the getElementById method provided by the DOM API across browsers instead of the $(#id-here) accessor exposed in jQuery. Historically, developers had to rely on libraries to provide support for functionality that wasn’t standardized across browsers. However, with technologies like polyfills, more uniform support for APIs across browsers, and advancements in JavaScript language features, it’s more feasible for developers to rely heavily on standards.

Among the tougher elements to modularize on web pages are events that cause changes in different components. For example, a user might click on a button that will update a form field and submit a request to a backend API in a single interaction. Oftentimes, this is managed by integrating all of the related elements, the button and the form field, in one component and leveraging state to toggle the view or contents of each element. But this can quickly get out of hand. What if, in addition to updating a form field, we need to render a new UI element?

In lieu of adding more and more logic to our button component, we can implement a standardized interface for sending messages across different components within our page. In fact, the browser already supports this scenario via event listeners. Instead of coupling the logic into one component, the button element can dispatch an event that other components can listen and respond to.

The state

So far, we’ve covered styling and event handling, but there’s one thorny topic we’ve yet to discuss: state. Frontend applications store a lot of state, such as the contents of a user’s timeline or their current application settings. How do we structure the state of an application to improve modularity?

First, we can ensure that state is only associated with the components it’s related to. For example, a sign-in/sign-out button doesn’t need to access state about the contents of a timeline, so this information should be completely opaque to the button.

For scenarios in which state doesn’t need to be shared across multiple components, state modules can be implemented to manage the state for a particular class of components. The state module provides a set of getters and setters that each component can access and ensures that components cannot make conflicting or unexpected changes to the state.

Underpinning styles, state, and event handling is the structure of the frontend itself. This is often determined during the design of the user interface. To lend itself to modularity, the design of a web page should isolate related state into a singular component on the page. For example, the list of products a user recently purchased should be rendered independently of the list of products currently for sale. Also, user actions, such as liking a post or deleting a comment, should only be executed via a singular UI element.