Maintaining a Component Library at Scale

Rate this content

This talk is about an example approach on how to organise maintenance across multiple teams, where we talk about how we came to this plan at Jumbo and what benefits it brings to the Developer Experience while being able to continuously deliver features to our customers.

We're dealing with maintenance, ownership, adding small features, upgrading from Vue2 to Vue3 and the culture that supports this way of working.

9 min
01 Jun, 2023

Video Summary and Transcription

Jumbo, a grocery chain in the Netherlands, has a tech campus with over 400 developers working on digital solutions. They built a distributed component library called Kompas, allowing everyone to contribute and ensuring knowledge is not lost. They adopted a hybrid solution, combining centralized and decentralized approaches, for fast development while maintaining a clear vision and high-quality standards. The key takeaway is to be willing to change processes and find what works best for your organization or team.

Available in Español

1. Introduction to Jumbo and Kompas

Short description:

Good afternoon, everybody. My name is Joran. I work for Jumbo, a grocery chain in the Netherlands. We are a grocery chain in the Netherlands or Belgium. I wanted to share our story with you. We have a Jumbo tech campus with over 400 developers working on all our digital solutions. We value the omnichannel experience and built a design system called Kompas to facilitate it.

Good afternoon, everybody. As you can see, it's a big screen. It's really super bright. My name is Joran. I work for Jumbo, a grocery chain in the Netherlands.

Quickly, who is from the Netherlands or from Belgium? Who does their shopping at Albert Heijn? We have some work there, but we'll get there. We are a grocery chain in the Netherlands or Belgium. I am going to talk about if this thing works. It does. About LEGOs. But actually, a components library. We did a thing at our organization, and I wanted to share our story with you. Bear in mind that this might not be the perfect solution for you because you have a different organization, different needs, and a different environment, but it works for us. I hope that I can at least share it through our journey and give you some inspiration to take home.

As I said, we are a grocery chain in the Netherlands. I'll skip through this slide because it's just 10 minutes. It's a short amount. In order to do our e-commerce solution and all of our in-house products, we have a Jumbo tech campus where we have over 400 developers working and they work on all our digital solutions. That's not just the e-commerce, it's also the machine learning stuff, the data lakes, everything, but we also do web and we also do frontend, fortunately. That's where I come in as well.

What we at Jumbo value highly is the omnichannel experience. That means for us, at least, that we put the customer first. We think that's really important for us as an organization because from a customer perspective, you're dealing with Jumbo and not necessarily Web Team A or not necessarily a store representative. Everything that is coming from us should be, or should feel at least as familiar to you as it is, it's the one big part. This omnichannel experience is really important to us and in order to help us in facilitating an omnichannel experience, we did something that a lot of people do. We built a design system and our design system is called Kompas, which is Dutch for compas. I hope that translates well. We did a good job there, I think. But this helps us in making good decisions and how we are designing and developing our products. A little bit of background information about our component library, and again, I won't go into detail because you're not interested in our view setup, but it is built in Vue Storybook for documenting our resources.

2. Building a Distributed Component Library

Short description:

We built our component library from scratch to deliver highly specific features. Instead of having a dedicated team, we took a distributed approach, allowing everyone to contribute. This creates a sense of investment and nurtures ownership. Distributed contributions also ensure that knowledge is not lost when team members leave. Having a large team of front-end developers contributing helps in delivering features. Additionally, every increment added to the Component Library is immediately usable by other teams, making product owners happy. To maintain consistency, we set clear rules for contributors, including upfront communication, reusability, and simplicity.

We have a couple of actions as well, and I see Chromatic is there, so those people should be happy at their stand. Same company. So we use that as well.

Our component library, we built that thing from scratch because it makes sense to us in order to deliver our highly specific features. Now, if you build a component library from scratch, that takes a lot of time and effort we made a decision to not go with a dedicated team, because the simple reason, or the assumption actually is that that would introduce a large bottleneck for our entire organization. And that's something that we want to prevent. We want to be able to have our teams move as fast as possible because we want to get features out the door so that customers can order more groceries online. So no dedicated team. And what we did do, and I'll explain this in a bit, we took a distributed approach. And for us, that meant that everybody who uses the Component Library is able to contribute to the Component Library. So let's explain these benefits that we see, or that we saw at least. And the first is, and I think this is the most important one, and is still valid to this very day, that everybody who contributes to a library has some sort of a sense of investment or some nurturing, what you would call it. Something that you want to take care of this, right? Because you own it, you build it, you maintain it, so it's yours, and you feel some sort of investment, which I think is the most important thing.

The other thing as a benefit is that it happens sometimes that people leave your company. And what you don't want is that they take all their knowledge, their highly specific knowledge of the Component Library with them. So with distributed contributions, you also have distributed knowledge. That's our assumption. And the next thing is that if you have all of these front-end developers contributing, then you have a massive team who is helping you in delivering features. So this is also a good thing. And lastly, the last benefit that we saw is that every increment or everything that you add to the Component Library is immediately usable by all of those other teams. This makes product owners very happy, and we want to keep them happy to have sensible sprints. Let's see what's next.

Yeah, this is also very important. So if you have all of these contributors on your codebase, you need to set some rules. We basically said that if you want people to play your game, you need to have a clear set of rules so that everybody is actually playing the same game, and that it's clear what can be done and what cannot be done. And we started out with a couple of simple ones. It's very straightforward, I guess. You need to communicate upfront what you're going to be changing on the Component Library, make sure that it is reusable as a component and not highly specific to your team's needs, and keep it as simple as possible. And this worked very well for us. So we are very happy, we're working, we're working, we're growing in teams and complexity, and then stuff happens.

3. Addressing Snags and Choosing a Hybrid Solution

Short description:

We encountered snags along the way, including a major upgrade from Vue 2 to Vue 3. We revisited the idea of a dedicated team and realized the benefits of both centralized and decentralized approaches. Instead of choosing one, we adopted a hybrid solution where teams contribute to the component library with vision and guidance from a central team. This allows for fast development while maintaining a clear long-term vision and high-quality standards. The key takeaway is to be willing to change processes that don't work and find what fits best for your organization or team.

We encountered a couple of snags along the way, which slowly started to pile up until a point where we needed to address them. You can read about them. One of the examples is a major upgrade from Vue 2 to Vue 3. It happens in every framework or library that you have to do some maintenance. And this was not addressed by business features. So there was a sort of a problem. And if you have a problem, you need to find a way to fix this.

So we started to revisit, again, the idea of a dedicated team, because it also has some benefits. Let's see, I am for time, but this is fine. So the centralized and decentralized approach, they both have their drawbacks and their benefits. So some of the drawbacks are listed here. So this means that our decentralized had no clear ownership or direction. And they also have some benefits. So the decentralized is very fast. And the centralized has a very clear vision. And we think that vision is also highly important.

So what did we do? Well, we had to choose, didn't we? Well, actually, we chose nothing. We chose a hybrid solution where we are now currently in the works of investigating this new model. And we have sort of a hybrid approach where we still keep the teams contributing to the component library, but they have vision and guidance from a central team. That is basically sort of a shepherd of the component library. So they guard the long-term vision, they guards the quality. And at the same time, we have all of those teams who are still able to contribute with high speed so that we are still able to develop in a proper way. That's how we do it. And I wanted to end this with sort of the final takeaway. If you take nothing away from this talk, then please bear with me, because this is basically what it's all about. The process we started out with worked for us in the beginning, and we noticed over time that that process needed changing. What I'd like to give away should be obvious, I hope, but if there is something that doesn't work for you, then please change the process or change the way you do things to make sure that you actually end up with a process that fits within your organization or your team. I'm doing very well with time, so I'd like to thank you. It's been awesome being here and talking to all of these people.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.