Just a few days ago we open-sourced the React components we use to build the . bit.dev platform A quick look will show you that we actually opened-sourced not 1 GitHub library, but 2 different codebases. In fact, independent components with different versions are mixed from both codebases to create every page. The first codebase is - a generic set of infrastructure-UI React components used across the bit.dev website. base-ui The second codebase is - the concrete React component design system we use to build the bit.dev marketing website. Evangelist Separating these components into two different front-end codebases (or " " if you will) is part of how we manage reusable React components in a scalable and collaborative way - to speed our development and ensure a consistent UI across apps and screens. component micro-frontends In this post I'll show you how we manage our reusable components in React, from development to integration in our applications. I'll show you everything from A-Z: 1. Different component codebases. 2. Exposing components for reuse and integration. 3. Composing pages applications. 4. Collaboration and updates. Let's get to it. 1. Different component codebases We build our components in different codebases according to the different scopes and teams they belong to. For example, the concrete marketing components (pages, sections, content) is maintained in a different codebase than the infra-ui components (layout, atoms, themes). Is this considered ? Depends on . What I can tell you is that we are able (thanks to which I'll show you in a sec) to build and maintain these sets of components in decoupled codebases and expose components to use elsewhere, which is similar to micro-services. micro-frontends who you ask Bit Take a look at the where we build some basic UI components in React like Card, Image etc. This codebase is much simpler than that of an entire application, making it easy to develop. base-ui repository on GitHub And then there's also the where we build  concrete components (sections, content)  to use in our marketing pages. " " GitHub repository Evangelist This kind of flexibility also provides us with the freedom to , so that different teams can own different sets of components, regardless to where they are used - in which page or application. split team ownership For example, if you are building an "Airbnb" application, it makes more sense for the "hotels" team to maintain their concrete card-carousels than to demand on a single infra-team for 100% of the components they need. 2. Exposing components for reuse and integration. Next, we use - a tool of our own making now used by thousands of people -  to . This container is called a Bit "Capsule" and it contains everything the component needs to be used elsewhere: all files, dependancies, build configurations etc. Bit automates this process for you. Bit place each component in a front-end "Container" Bit and lets you export a bunch of components to - the component hub we created for teamwork. It's 100% free for open-source and for some private code too. applies a standalone version to each component Bit.dev For example here are the components exported to Bit.dev: Evangelist https://bit.dev/bit/evangelist And here are the base-ui components exported to bit.dev: https://bit.dev/bit/base Now we have to sets of components on bit.dev (called "collections"), one for the marketing components and one for the base-ui components. Each collection is a group of independent components which are standalone versioned, can can be integrated into any new codebase. There are two ways to integrate a component: 1. Install it as a package from the bit.dev registry using npm/yarn. 2. Use `bit import` to source the component into a new codebase and make local code edits. It's managed by Bit so you keep getting updates. Note that bit.dev also run CI for every component version, and since it "knows" about the dependents of each component, it lets you make sure every change you make doesn't break other components elsewhere. You can see each component's version build and test results in its page. It also auto-extracts the docs from react components (TS/JS) using react docgen,  to help document each component. And finally, it provides each component with a live playground to try it out and save visual examples. So now basically you have 2 codebases with 2 different sets of exposed components, each maintained by a different team- while everyone can easily find and use these components in their own pages and applications. 3. Compose pages and applications So now let's say you have a 3rd project which is an application you build for your users. You can have more projects and it will work the same way, since everything is now 100% reusable as well. All you have to do is choose a component and integrate it into your application. As we mentioned above, there are two ways of doing that. Well in fact three, as one and two can be combined together (recommended). 1. You can rely on a regular package-based build-time integration by installing independent components from your bit.dev collections. $ npm i @bit/bit.evangelist.atom.eva-button yarn add @bit/bit.evangelist.atom.eva-button # or 2. You can use `bit import` to source any component's source-code into the consuming application to make local edits. This is very useful for a quick integration that required modifications. As the component is still managed by Bit, you keep getting updates on top of local changes. bit import bit.evangelist/atom/eva-button 3. Combine the two methods: install components at packages, and when you need a change use `bit import` to quickly get the source-code and make changes right from your application. Then eject and move the component back to begin a package dependency of the application. One such example is actually the ! If you head there you will see that it contains components from both and , all Cool, right? bit.dev homepage Evangelist base-ui, with different versions mixed in one page (!). : your application is now built in a few separate component-codebases, all your components are exposed and made reusable in the cloud, and you can compose and integrate them to build front-end apps. The result 4. Collaboration and updates Ok so finally, here's one more cool aspect of the way we work. Most teams build a giant monolithic single-versioned component library. We prefer to build with independent components. It's much better to be able to mix&match component versions, get focused relevant updates only to the components you actually use, and make it easy to hotfix/rollback. You can learn more about this best practice here: The Case for Versioning Independent UI Components Anyways, since we expose and reuse independent components, we can update specific parts of our UIs and easily control the changes across multiple projects and applications. For example, when a new version for component will be available, all the pages and applications that use it can get an update to that component, without having to bump versions for any other components. Evangelist's "eva-button" Any even better, if a developer needs to make some quick changes to the component to fit it into a new app, it can then just use `bit import` to make the changes right from the new project- and even share them back to bit.dev as a new version of the component for future reference. This makes it much easier not only to adopt and integrate components, but also to make sure every page in every application is always up to date. * There's that shows this workflow where you get and deliver updates to a component from two different codebases. a short 5 min video demo Conclusion - sum up Building front-end applications from components maintained in decoupled codebases helps us scale front-end development. It also helps us split ownership of components between developers and product teams. We use advanced tooling like to expose and integrate components from one codebase to another with the power to balance the advantages of with the ability to scale to many components. Bit independent components Having all our components shared in one central hub lets our entire dev team collaborate on components, get updates and stay in sync. It also makes it easier to save time on component documentation. I hope this is interesting for you to read and maybe it can be useful - all or some of it- in your own work. A good place to begin is just to export some components from your app or library to bit.dev and gradually build your reusable component collection. You can split codebases later, or not. Enjoy and thanks for reading! Jonathan

AirBnB

BUNCH

I write code and words. Learn about Bit: github.com/teambit/bit

Read My Stories

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

How to Manage Reusable UI Components

Too Long; Didn't Read

Companies Mentioned

@ysaring

RELATED STORIES