⚙ Shared Components: Project example of shared React components
- Specific tips to make you accelerate
- A playground: You can copy paste the repo entirely to reuse it as is
Key learnings!
0. ⁉️ Should you develop such a project?
From our experience, we proved in which condition it is valuable to share components between apps: find out more with this article.
1. 🧐 Use a mono-repository
Split your responsibilities and domains in different packages, but have them all in one place for a smoother developer experience. We use Lerna for managing our mono-repo.
2. ⚛️ Follow "Atomic Design" principles
An atom is a very small dumb and highly reusable component, while an organism is a full grown one-page business connected feature. It all comes from Brad Frost Atomic Design principles. You can find diagrams of the project architecture here.
3. 🎪 Display it all in one unique showroom: Storybook
We use Storybook to develop and showcase our components! One central and unbiased place, forcing any contributor to always think reusability. To try it, install the project and run yarn start.
4. 🔨 Simplify your packages versioning and beware of breaking changes
Use automatic versionning (commitizen), changelogs and type systems (Flow or TypeScript) to prevent messy bugs because of unanticipated breaking changes.
5. 🏭 Create new components/libraries with a "generator"
Make sure that any new component follow the same design choices by using a "generator" like Yeoman.
6. 💄 Define your customisation strategy
We used Styled Components themes and an additionnal service of ours to define how our components can be customised. Find here more details.
7. 🌬 Make your packages light
By building your packages as ES6 modules, your users will just bundle what they need. You can find out how we did here
8. 👮 Control what components and features enter the repo
Developing on "Shared components" is heavier than on a normal project, hence taking the decision to create a new component should be well thought. We recommend to plan at least 3 reuses of the component to make it worthwile. Here is our decision tree to help us make that decision.
9. 🛣 Define a strict feature branch Git flow
For us, all feature branches start from Master. PRs are first merged on Develop. Then on Master. Regularly, we automatically merge Master in Develop to keep them aligned.
10. ♻️ Regularly update your dependencies
More than any other project, "Shared components" has to be aligned with the latest standards, as new projects might launch and need to be compatible with it.
11. 👩💻 👨💻 Dedicate a core team
Just as an open source project, have a dedicated tech and business team focused on making "Shared components" a success. Without a core team, you won't have the focus and ownership necessary to handle such a project, hence the complexity and debt will accumulate and your developers will end up losing more time than winning, in the long run. We will be more specific in a dedicated article later on.
12. 🔗 Ease the Yarn Link pain
If you want to locally test your component on your host project, you'll have to use "Yarn Link", we learned how to deal with it.
Locally start the project
If you want to try the project out and at first launch the local Storybook: follow the installation steps here!
The stack
Roadmap
- Finish the MVP: main readme + global article + basic Storybook running locally
- Share online to see if it interests people
- Have an up and running project with working CI and hosted Storybook
- Deep dive on key learnings with further articles and project improvement
- Update of the repository basis to make it a boilerplate
Contributors
 Aurélien Le Masson |
 Michel Parreno |
 Hugo Lime |
 Justine Mignot |
 Surya Ambrose |
 Ivan Poiraudeau |
 Xavier Lefèvre |
|---|---|---|---|---|---|---|
 Albéric Trancart |
 Darya Talanina |
Powered by
 Theodo |
|---|
License
Shared Components is MIT licensed.