Faster Integration with Web Components

During weekly meetings, we were stunned when our client’s developers shared how they had already integrated the components we had finished mere days earlier. This doesn’t normally happen. It often takes weeks or months before clients integrate design systems.

It was such a delight to see our work integrated in near real time that we rearranged our meetings so we could start by unwrapping the integration demo gifts.

On most projects, clients can’t keep up with our velocity. I don’t say this to brag or disparage others. We’re not speed demons. We prioritize quality over speed.

But client teams have other priorities and challenges that we don’t. We focus on one project at a time and that typically means we can move at a faster pace than our counterparts.

On this project, their developer was waiting on us. What was different?

At first, I thought their developer must be a superstar. But other developers joined the project and the fast pace continued making this theory less likely. Their developers are truly exceptional, but I no longer believe this is the primary cause.

I wondered if their technology stack made integration faster, but that seemed unlikely. Their stack is old. They have plans to replace it.

It was only when reviewing a modal component that I began to understand how web components themselves were changing the speed of integration.

Modals are problematic. They present challenges on small screens and for people using assistive devices. We try to avoid them when possible, but they were unavoidable here. There wasn’t time to remove all of the modals in the short run.

These modals also required more functionality than any modal we’ve ever designed. On large screens, multiple modals can open at the same time. They are draggable and stackable. Modals can open other modals.

Making modals work on small screens was the challenge. I’m pleased with the end result. I jokingly called them the most flexible modals ever designed because of their many features:

• Accessible (we are most proud of this)
• Responsive
• Themeable
• Draggable
• Short or long content
• Modal or a sheet UI
• Navigation between modals
• Animation

Creating a modal that could do all of this required thoughtful consideration and hard work. Under the hood, the modal component is composed of more than 10 sub-components. But that complexity is not passed on to our client.

To use a modal, all you have to add to the HTML is:

<wc-modal title-text="Title">Content</wc-modal>
Code language: HTML, XML (xml)

That’s it. Use the modal’s custom element, <wc-modal>, and watch the component do all the heavy lifting.

Most modal markup won’t be quite that simple. Typically, there is some configuration. And the main integration task remains: supplying the right content to the modal.

But most of the modal complexity is taken care of by the component itself. The developers working on integration don’t have to worry about how to handle focus trapping or animation.

It is a strange bit of cognitive dissonance to both advocate for web components because they make integration easier and to be surprised when they actually make things faster. Other than finding ourselves on the critical path more often, it is incredibly exciting.

In the past, we might have provided a series of guidelines on how to make modals accessible and hope the implementation adhered to our recommendations. With web components, we can take on that burden for our clients so they can focus on the specifics of their applications and be confident that the component will take care of the rest.