Sharing Components is Caring
A real-life story of one component and two applications
Why Share Components?
A story of two applications
Here is a scenario which may look very familiar:
SOSA company has two code repositories: Shoppy is an online shopping e-commerce application, and Stocky — an inventory management application. Jane is a developer in the Shoppy team and her colleague, John, is working in the Stocky team.
Recently, Jane has developed a great product-list component for displaying products in Shoppy. John has seen Jane’s component and would like to use it in Stocky. He realized that this component would be great to be used in Stocky to show the existing products and updating their current Stock. John is inquiring into Jane’s code and sees that the product-list component depends on an external npm package for showing a grid.
How To Share Components?
What are John and Jane options? They really just want to quickly share the component, and keep it updated later on.
Option 1 — Copy the product-list source code
John has access to the Shoppy repository and he is copying the source code of the product-list component to the Stocky repo. However, to make the code work he needs to install the npm dependency and copy the product viewer code.
The process of identifying all the required dependencies in the project is lengthy, cumbersome and requires multiple copies. Not only the source code needs to be identified, but also related test files need to be copied and maintained in the Stocky repository.
At the end of the process, 2 separate copies of the same component exist in 2 different repositories. Any fix or change that Jane is doing in her component locally will not be reflected in John’s code and he will need to implement the same change himself.
It saved John some coding and debugging, but the future does not look bright.
Option 2 — Moving the Component to a separate Repository
John Asks Jane to move the code into a separate repository. This requires refactoring work from Jane. Luckily for John, Jane is a friend and is willing to do so. Both John and Jane are now installing the component from the third repository. While this initially works well, Jane’s work is now harder, as she ends up working on multiple repositories.
Jane and John also understand that moving components to a separate repository will require a distribution tool, such as using a private npm registry to share or using git sub-modules or sub-trees to access multiple repositories.
Working with multiple repositories also adds a great overhead to debugging. Debugging the package outside of its original context, as well as using links to work with it in the application context can become hard.
The team also realizes that while this pinpoint solution may be useful for few components, it will become a maintenance nightmare in the long run when more and more components will need to be shared with other repositories.
Option 3 — Using a mono-repo
In the last years, using a single repository (mono-repo) for all applications has become a common practice. The main goal was to try and solve exactly this projects reusability problem. In a mono-repo, all projects are located in a single repository, and multiple applications can share the same code.
John and Jane would like to have a single mono-repo for the applications, however, this requires an overall organizational change, which is not likely to happen in the forthcoming future.
While mono-repo has multiple benefits, it also has some drawbacks:
- Established in an existing environment — if a project is starting from the ground up, building a single mono-repo can be the right solution. However, integrating this process into an existing infrastructure may require a large investment which is not always possible.
- Mono-repos require strong tooling to let it work as a set of single repositories. While some larger companies such as Google use such tools, not every organization has the capacity to introduce those changes. You can read more here.
- Mono-repos make it hard to secure parts of the code. In some scenarios, it is not desirable for everyone to be able to change any piece of code. Also, it is impossible to let only certain people, such as external contractors or collaborators view all of the code. It’s also hard to open-source parts of it.
A Better Option — Share Components in the Cloud
A better option will be for Jane and John to focus only on the component they want to share. That means that only the code of the component, with all of its files and dependencies, will be shared between the projects. Both sides could suggest changes and receive updates to the component.
Let’s think of how this workflow should be like:
- The original author, Jane, marks all the files she wants to share that create a single reusable component or module. That means — the relevant HTML and CSS files if exist as well as test specs that are related (Jane is famous for writing good tests).
- A designated tool will bundle all the files of the component with all their dependencies to create a shareable unit that is uploaded to the cloud.
- John is building his own app and could really use Jane’s component.
- John is searching in their shared component cloud, looking for such a component. He finds Jane’s component.
- John is playing with a live version of the component, checks the requirements and is also peeking at the code. He decides to use it.
- John can choose if he wants to install the component as a project dependency (that is, doing an npm or yarn install), or if he wants the actual code of the component to be added to his project.
- Whenever there is a new change, John can update the component with the new installation or with the updated source code.
- If John sources the actual code of the components in his project he can make modifications to the component and submit them back to Jane while keeping the changes in his project.
- Jane can accept John’s changes and fixes, and submit a new version of the component. John can now install the new version.
In this flow, only the code of the component, with all of its dependencies is packed and uploaded to a remote cloud service. No local repo cloning, no complex setup.
The original project, Shoppy, still has the code of the component and Jane can make any changes she wants and test it to it without going through advanced maneuvers.
Stocky will only consume a reflection of the original code, which is still pointing to its original source. John is able to get any updates Jane is making to the component, but without copying the code.
The projects code structure will stay the same and there is no need to go through large code restructuring to get to the point that the code is shared.
Learn more about Bit to share components between your projects in the cloud, collaborate and build faster as a team.
Summary
Sharing components between projects can accelerate projects development. It can simplify the maintenance of your apps, and help you build better software. And yet, existing practices do not always achieve the efficiency and effectiveness we would expect. To make code reuse and components sharing a breeze, a new generation of tools is needed, built for components
