Maintaining a component library at scale

Jumbo’s site and app may look simple enough, but just the homepage alone holds more than 50 components that help shape and add content to elements like price tags, menus, and headers. Jumbo.com and its proprietary component library (Kompas) are built on the Vue framework. How are we maintaining a component library at this scale?

Before we dive into the topic, a little bit of context would be necessary because we’re going to talk about a solution that works for our organisation. Having context helps you in deciding if and what would work in your situation.

So at Jumbo Supermarkten we cater to a big audience. We deliver groceries all across the Netherlands which means we have a big stake in our e-commerce platform. As a big company, we also have a big stake in IT solutions to get our businesses running. A lot of our software and tooling is build in house.

In fact, there’s a whole department of IT specialists, at the Jumbo Tech Campus, collaborating on digital products. To accelerate our web product development, we’ve built and are maintaining our own component library.

We’re using VueJS as our framework of choice, and yes, there are off the shelf solutions we could apply. But we didn’t. And we think we have very good reasons for doing the heavy lifting ourselves.

• We have a need for more specialised components.
• We believe that a component library should match the brand and not the other way around.
• We know our customers better than from the perspective of a generic set of components.

Kompas

Our component library is an essential part of Kompas. Kompas is the name of our design system. It helps us with aligning designers, developers and other stakeholders in teaching us to speak the same language. The goal of Kompas is facilitate with quickly building applications according to the rules we’ve set out.

Putting the customer first

At Jumbo, our philosophy is to put the customer first. A way of supporting that is by providing an Omni Channel Experience. This means that from a customers’ perspective, you have the most seamless interaction with any of our products or service because you are dealing with Jumbo as one entity. To make that as seamless as possible, it just makes sense to use and reuse components and their interactions as much as possible. Because for the online part at least, you then have a familiar interface to deal with.

So we’ve established that a component library makes absolute sense and we even encourage to reuse not just visual components, but also more elaborate interactions, strengthening the Omni Channel Experience across our solutions.

Now it takes effort to build and maintain a component library. You could do this with a dedicated internal team, working around the clock on adding new features via requests and maintaining the product.

A distributed approach

We did something else. We took a distributed approach, where every team using Kompas is also part of the Kompas team in a way. In practice, what could happen is that you work on a feature and simply use Kompas to fulfil the business need. Or you find that a component in Kompas is not capable of meeting requirements. In that case, what happens is that a developer modifies (expands) the component in Kompas and uses the latest version to fulfil the feature. Kompas is being improved based on business features.

We believe this benefits us, because of a couple of reasons that fit within our companies’ philosophy.

• Having this setup establishes an investment in the library. Since you’re using and building it, you have a responsibility to keep it purring like a happy kitten.
• A distributed approach also ensures that knowledge is distributed across the development teams.
• We have short feature cycles on the library, because as a developer you have the freedom and responsibility to modify the library when needed. There’s no dependancy on another team.
• These small increments are immediately released, which means that other teams immediately benefit from any improvements.

Rules and guidelines

If you want people to play, you need to set clear rules. And we did. The most important one is about communication. Share upcoming changes, issues you’re facing and share successes!

If you’re adding features or new component, also ensure the reusability of the addition. Since you’re adding from a business feature point of view, it is likely you need to do some decoupling of the feature and underlying component.

To ensure the quality we set out to automate as much as we can, which seems obvious if you think about it. Anything repetitive should be automated. This doesn’t only save time, but it also serves as a more objective way of measuring additions. It’s less opinionated than sifting through a pull request when somebody has a bad day.

So this works really well! We’re improving our component library on a daily basis, by small increments that everybody can immediately use. This is great!

What about..?

There is, of course, a caveat. What happens when you need to work on bigger topics? We do need to upgrade dependencies every now and then and that is something that doesn’t fit in with the concept of improving by adding features. There’s also the devops related activities that fall in similar categories, or even adding or replacing tooling solutions. These are no daily challenges, but they do pop up on a regular basis. Turns out, we have a fitting solution for that as well.

At Jumbo, we are encouraged to spend 30% of your time on stuff that is not team related but helps Jumbo in the long run. That is a generous amount of time, if you think about it. What we see happening is that people feel responsible for Kompas. So when some of these issues arise, people seek each other out to solve the issues. The nice part is that people from completely different teams are seeking each other out to work on a common task from their own interest and motivation, which is awesome.

We’ve now been employing this way of working for a couple of years. During that time we’ve seen the library grow and tooling come and go. The distributed module works for us!