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 frontendapplications?
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 thefrontend.
With great complexity comes great bugs and even greater maintenance burdens.
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 forthis.
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 theUIwithout 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 thefrontend.
The what
The principles of composability and modularity are often interlinked. Modular systems consist of subcomponents with well-defined interfaces and functions that can be consumed independently of each other. Composability is the degree to which these subcomponents can be combined to form more complex systems. Despite the similarities in these definitions, a modular system isn’t automatically composable. A system’s subcomponents can have well-defined interfaces and scopes but be difficult to integrate because data types aren’t generic enough across subcomponents, or because certain subcomponents may have unexpected sideeffects.
The why
When implemented in frontend systems, these principles offer many benefits to both developers and end users. For starters, it’s much easier to introduce new features or deprecate unnecessary ones in a modular system because the subcomponents aren’t deeply coupled; changes are much easier toisolate.
Composability and modularity also make it easier to maintain (and document) existing code. Instead of sifting through hundreds of source files to establish the relationships between different components in a system when making a feature change, an engineer only needs to examine one component of the system and understand the interface of others. You can imagine how much time that saves during both development andonboarding!
Last but not least, modular systems, in which components have limited scope and their internal complexity is obfuscated from other components, are much easier to unit test than monolithic systems. Since modular components are less likely to hold extraneous internal state and more likely to operate deterministically, there is less unexpected behavior and fewer side effects to account for whentesting.
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, andDOMmanagement.
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 orUIlibrary.
Styling frontends with CSS can quickly become a gnarly affair.
Let’s start off by covering something universal to all rendering libraries: styling. Styling frontends withCSScan quickly become a gnarly affair. Often, the styles applied toHTMLdepend largely on the structure of the page. In the example below, thenavelement is aware of its position on the page and has a childbuttonthat’s aware of its inner content. This pattern doesn’t lend itself to modularity or stylereuse.
<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 existingUIlayout.
<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, composableCSSpatterns avoid applying styles to tag-basedselectors.
h1, h2 {
font-family: Arial;
}The first of the three previous patterns is a global-level style that modifies allUIcomponents within a page, as opposed to the approach in the second code snippet, which can be appliedselectively.
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 standardizedAPIs, when possible. This makes the frontend system resistant to breaking changes in third-partyAPIsfor fundamental logic such as manipulating theDOM:for example, relying on thegetElementByIdmethod provided by theDOMAPIacross 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 forAPIsacross browsers, and advancements in JavaScript language features, it’s more feasible for developers to rely heavily onstandards.
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 backendAPIin 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 newUIelement?
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 respondto.
The state
How do we structure the state of an application to improvemodularity?
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 improvemodularity?
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 thebutton.
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 thestate.
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 singularUIelement.
The future
The principles of modularity and composability are codified in the implementation of micro-frontends. Micro-frontends are structures for creating frontends in which each component is isolated into its own application and rendered collectively on a page using mechanisms such as Web Components or iframes. While this approach maximizes the composability and modularity of a web application, it can be difficult to migrate existing frontends to this pattern. Furthermore, it takes a fair bit of work to integrate all of the subcomponents and ensure that they work properly. Leveraging some of the implementation patterns we’ve discussed provides a good migration store for existing frontends and strikes a balance between the technical benefits of modularity and the cost of migrating existingsystems.
As the web advances and users demand more and more from the frontend experiences applications provide, we’ll need to design frontend systems with composability and modularity in mind. Favoring these design characteristics makes it easier to onboard engineers to existing frontend components—and to maintain and grow successful frontendsystems.
