How to Update or Change UI Component in Many Applications

The true story of how one company changed its logo in 600+ modern applications — in one day.

Jonathan Saring
Bits and Pieces

--

A couple of months ago a world-class web infrastructure team arrived at the bit.dev platform. It was a large Fortune-50 tech company working on 600+ modern apps worldwide. They build tools I use every week.

This large company had a very particular problem to solve:

How to update their company logo in 600+ UI applications.

At first, this sounded funny. What’s the problem? Just ask every team to use the new logo version, in all their products and pages.

Turns out this “simple” task turned into a 6 months voyage already, and success was not anywhere in sight. I had to ask them “Why?!”

The answer I got was that they just had no way to do it. The logo was a React Icon component internal to each and every one of their applications. Every team was building a monolithic app, and so every team had to manually make the change — and deploy it.

They had to reach out to over 70 teams and get them to prioritize the logo change in over 600 applications. Needless to say, it was not their priority.

But, this change can take less than an hour to complete, in all apps.

This velocity and harmony can be achieved thanks to adopting CDD or Component-Driven Development in modern web applications, and by using modern tooling to share, manage, and integrate components across apps.

So what is Bottom-Up Component-Driven?

Imagine a castle of Lego, built of pieces. Each and every piece has a defined function and is “standalone ready” before composing something larger. When pieces are modular, replacing a piece is quite simple, right?

Now imagine that you are building 600 different Lego castles. Each of them has some % of pieces shared with the other castles.

When you change one piece in the outer wall or in the tower, you’d like to see all outer walls and towers updated with the new piece in all castles. If you had a system that “knows” where each component is used, and all components are independently versioned and managed, then this should be pretty simple.

From Lego to Modern Apps

Modern applications are built using component-driven technologies like React, Vue, and Angular. A company Logo, for example, is just an Icon component. You can, in theory, just replace it with another component.

But what happens when this component is internal to every single application? It’s just code written and coupled inside every app. Then, you have no way to manage and update the component across applications.

Bit: Updates are just new component versions

Yet, if you build independent components first and then use them to compose applications, you can make it much easier to replace anything, anywhere. And if you adopt a modern CDD infrastructure like bit, you can easily and safely update components across multiple apps with a simple version bump.

“Build component, not apps” — Latency Conf 2020

Let’s go back to the case of the Fortune-50 company and the Icon component:

The problem was that their logo was implemented internally in every application. What they needed was a way to turn these components into independently versioned, shared, managed, and updated modules.

Old solutions like npm were built for projects, not components. They are not practical for many small components used to compose many applications. They require too much overhead and don’t allow collaboration.

Bit v15 ‘Harmony’ is like Git for components, but with dependencies. It helps you build component-driven apps in a modular yet simple, scalable way.

Using Bit you can develop, version, and compose independent components into as many applications as you like. It gives you a very simple and smooth dev experience even in large complex projects with many components. Every component comes with dist files and all, making it instantly reusable.

Don’t worry; It plays very well with Git and every other tool in the ecosystem. And, it has a beautiful local dev UI that makes CDD fun.

Bit local dev UI— Develop and compose independent components to build apps

Updating many applications via remote

Bit hosts components in scopes, which act as component stores where they’re organized with release versions. A remote scope can be hosted o any server.

Bit.dev is an optional hosting cloud for components. It’s everything you need to manage, collaborate, and update components across many apps.

The above CDD app — as reusable components hosted on bit.dev -> check it out!

When you export (push) a component version to bit.dev, it can then be pulled by all applications using this component. You don’t have to ask people to do anything other than updating the components they use from Bit. Whether it’s with npm, yarn, or bit, it takes a few seconds and 3 commands. Easy.

Since every component is independent and developed in its own decoupled dev environment, it will be built and tested on every update — without having to build and test an entire app. And, Bit “knows” which other components depended on it, and will automatically update them all if you wish.

For the Fortune-50 team above, this means that changing the logo in 600+ apps means only to export a new ‘logo’ component version to bit.dev.

Furthermore, the bit.dev <> Github integration (beta) will translate every change into a pull request sent to all impacted projects - automatically! Then, smart analytics will help you learn who adopted which update, and where.

Ripple CI — Continuously integrate the organization

Ripple CI continuously integrates changes to the graph of components (shared and dependant) across the entire organization — all teams and apps.

When you push a new version for ‘icon’, Ripple will propagate the change to all impacted components (e.g. ‘header’, ‘homepage’) across all applications. It will build and test every component on the graph, and nothing else.

How Bit’s team is building component-driven apps with Ripple CI

Ripple is perhaps the most groundbreaking technology around CDD. Although still in closed beta (ask for access here), it already helps some great organizations change the way they build software together. It is 50x+ faster (building components, not apps) and free teams to release and adopt updates without fighting over main branches or waiting on bloated versions.

In the above example of the Fortune-50 team and the icon, a new Ripple (build) could be created, sending the new icon to all 600 applications. Ripple would build each and every dependant component and application, and each team could adopt the change as a GitHub PR — with just one command.

Changing a Logo in 600 apps in less than a day

A couple of weeks after first talking to that F-50 web infra team, they set out on a mission. Instead of asking all other teams to change their code to the new logo, they asked everyone to remove the implementation code altogether.

Instead, they had to install the icon bit component in their apps. That’s it.

Surprisingly, after the first few teams replaced the code with the Bit component, many other teams began doing it on their own. It was exciting to see, and soon they started replacing more of their code with Bit components. It took a few days for everyone to respond, but only a couple of minutes to do.

Next time there’s a change to their logo, the infra team can simply release a new component version to bit.dev — and that’s about it. Auto-updates will do the rest, and component-driven builds etc will make sure all goes smoothly.

A painful 6-month process turned into an enjoyable instant experience — thanks to thinking in components and working with smart tools.

P.S. ( 3 months later)

This post was originally written in March 2021 while Bit v15 Harmony was still in closed beta. Today it is publically available and widely adopted.

The infra team with the logo problem has gone a long way since then, creating over 300 components with bit hosted on Bit.dev, and shared them with all teams in the organization. These components include UI, but also things like shared Logic, Hooks, and even small useful NodeJS modules.

Now, they share components across most of their apps, and the infra team can constantly stream automated updates to all product teams. Every single day.

And, product teams began sharing their components too. The team has shown me over 50 components shared by different app-building teams, creating a truly collaborative and living component “economy” in the organization.

The team reports shorter development times, faster new-dev onboarding, simpler debugging, and about 10x+ more releases to production (!). Their goal now is to replace 75%+ of all code with components by 2022.

They like the new logo and don’t expect to replace it again soon though.

Thanks for Reading! 👐

--

--

I write code and words · Component-driven Software · Micro Frontends · Design Systems · Pizza 🍕 Building open source @ bit.dev