When and how to share UI components between apps?
At Theodo, since April 2018, we have been developing libraries of shared React components for one of our biggest client. We proved the value of maintaining such a project and stabilised its architecture and configuration.
Through this article, we want to share what a project of shared component means and in what situation is it worth doing one.
What is a shared components project?
If you are a developer, go to the next section.
If not, you might not know that apps are composed of two sources of code:
- Custom code
Business specific code meant to solve a problem in a new way.
Examples: Facebook or Airbnb websites, Uber app - Libraries
Openly or privately shared and highly factorised code solving a common problem meant to accelerate and strengthen the development of multiple apps.
Examples: React.JS framework, Material UI design system, Formik form manager
A type of library: Shared Components / Design System
Among those libraries, it is frequent to find some with pre-defined and adaptable UI components to help teams lay their UI much faster with much more consistency across all apps.
Examples: D3, Bootstrap, Material UI (again)
Should you have your own?
When re-developing very similar components several times it becomes interesting to develop your own library of shared components. It will:
- save development time across teams -> for not redeveloping the same components
- help align the UX/UI practices over your apps -> it centralises the UX/UI implementation, and brand design, in one single place for your entire company
- force an alignement and update of your technical stack across apps -> as future projects with the latest libraries will need to be compatible with your shared components
- more easily share business rules between teams -> when sharing components in your company you can also share the business logic, compared to open source libraries
Lately, we have seen more and more companies starting similar internal projects. Each of them having their own stack, design specificities or even business rules: they prefer having their own system. One of the latest in the series is Uber: https://eng.uber.com/introducing-base-web. You can also take a look at IBM’s Carbon Design System.
Here is a sneak peek of some of our own shared components:
How do I know my team should have a library of shared components?
What are the conditions to meet to maintain such a project?
1. 🚀 Many apps
Condition
- You have several projects in parallel and new ones get launched frequently
- Shared components become worthy if there is a re-use potential of at least 2 re-uses per component
Why?
- It is costlier to develop such a project: the development flow is heavier when contributing to libraries, the quality and documentation have to be of top quality because they impact several products and teams at the same time
- On our own project, we followed our ROI with care and proved that sharing components twice covered slightly more than their development cost
2. 🏭 One shared business and design
Condition
- Most of your projects share the same set of business rules and design guidelines
- Dev teams re-create extremely similar features over time
Why?
- If you share stateless components to make a design system, its main value is to unify the design across apps. Therefore if you don’t meet this condition, you lose the value of sharing: the components will become too customisable thus too complex to develop on
- If you want to share bigger and business related components, it means several apps exploit the same business data and rules
3. ⚙️ A unified stack
Condition
- Most of your projects share a same front framework, like React or Vue
- Technically, shared components require to have a similar base stack as their host apps
Why?
- The ease of sharing a component is entirely related to the library used to code it: embedding Vue in React is costly and can often be buggy/laggy
Let’s take an example:
I am part of a big bank’s IT team. Should I start a similar project in my company?
- 🚀 Many apps: The bank has always at least 5 teams working on different apps in parallel ✅
- 🏭 One shared business and design: All those apps share the exact same UX/UI guidelines, and they do have the same business data and logic powering them ✅
- ⚙️ A unified stack: The teams aligned their stack, they all develop using React, Redux and Styled Components ✅
🎉 All green, let’s start a shared components project!
Now that I am convinced, where do I start?
To help you kickstart or accelerate a similar project we open-sourced our entire set-up and documentation. There you will find our most precious learnings. You also have the possibility to copy paste the entire project and reuse it as is.
You can also find further explanations with the video and slides of my talk at React Foo in March.
What’s next?
We will continue improving and tackling the next challenges on our own “Shared components” project. Our plan is to pass on those future learnings through this open source repository and then deep dive some key aspects with more articles.
I hope that this article “brought grist to your mill”, and that it will give you even more reasons to start something similar, and help you make it a success.
Don’t hesitate to give us any feedbacks on the form and the substance in order to improve our recommendation and own implementation!
Were you planning on making a similar project? Or did you already try? And how did it go for you? Please let us know in the comments!
