Kickstarting a library of internal React components for multiple teams
In a company, as the technical teams grow and work on different projects, the question of creating a set of common components naturally arises.
This is what happened to us: over the years different teams redeveloped very similar components, from simple UI elements to complete business features. 9 months ago, it was time for us to take a step back and think: how can we do better?
This talk will present you our journey toward:
- What we’ve tried in the past… and the reason behind many failed attempts. 😢
- The technical design that worked for us, a mono-repository architecture with helpful tooling: Verdaccio, Lerna, React, Flow, Storybook, Yeoman… 🤓
- The indicators and processes that we set up to ensure that we maintain a good quality and speed of development. 📈
- And finally, the most important: how to onboard other teams in this long running task. 🧐
Today, five teams re-use and contribute to our common libraries on a daily basis, and other departments are expressing a big interest in it. And we even worked through extracting performance indicators, proving us that it was worth maintaining such a collaborative project - that could help you convince your co-workers that it’s worth investing time in such a project. You won’t regret it!
- The need of sharing components between projects
- Our failed attempts to answer this need
- The final successful attempt architecture, tools and development flow
- Our processes to sustain and improve such a collaborative project
- The key to onboard the other development teams
Professionally, I am the result of tangled business and technical interests. Coming from a business background, I am today an architect on web/mobile projects, with the aim to one day build a product that will improve people’s lives.