Component-Driven Collaboration

This article is outdated. Lean how to create and share independent components here.

Component-Driven Collaboration (CDC) is a way to build frontend code, as a team, by delivering code updates as meaningful . CDC can be contrasted by the "traditional" way of delivering updates with no clear borders, meaning or purpose.CDC is a way to maximize or even augment the benefits of Component-Driven Development.'Component-Driven Development' (CDD) is a methodology for building UIs from the bottom up, starting from small and , all the way to full pages. This methodology is, essentially, a "UI take" on an old and familiar concept in programming - modularity.

Just so we're on the same page - why CDD?

1. Building with independent components means more code gets reused as each component is built to be pure, independent and with a clear and explicit API.
   
2. Modular UI or component-first UI, is easier to understand, maintain and debug. The reason for this is quite obvious - atomic pieces of code are more predictable, testable and easier to comprehend than a single elaborate monolith.
   
3. Lastly, CDD also means a better separation of concerns as each component addresses a specific concern or serves a single purpose and needs not to know about the function of other components.

Getting the Most out of CDD with Bit and Bit.dev

 is a cloud component hub. It is a place to publish, document, organize and collaborate on individual frontend components (React, Vue, Angular, Svelte, etc.).

Published components can be installed using NPM/Yarn or cloned into any repository, using Bit's CLI. Cloned components can be updated in their "host repository" and published back to Bit.dev.

Bit.dev works perfectly with , an open-source tool for independent versioning and publishing of components. By using Bit, each component, in any codebase, can be versioned separately, built separately and published - you guessed it - separately.

Using these two tools, and a couple of integrations, I'll present a better way to collaborate on frontend code, a way that maximizes the benefits of Component-Driven Development. I'll use a simple demo app to demonstrate this and, hopefully, prove my point.Github repo:

Publishing components to Bit.dev - Maximizing code reuse

Building components as agnostic and independent pieces of code is essential for code reuse but not enough. To get others in your team to use your code it has to be both easily discovered and easily imported into different repositories.

Example

Let's say I've built my components and composed a much needed to-do app. Now, I'd like others in my team to learn about my great achievement and use my components in and across our different projects/repositories.For that I'll first need to install Bit globally.I'll then, login and initialize a Bit workspace in my project's directory.I'll then start tracking my components (each separately, remember?)I'll then want to configure a compiler to decouple my components from my project's build setup (again, each component is built separately).I'll then tag my components with a single version number, just to make things simpler (keep in mind - each component is actually versioned independently). The 'tag' command locks changes, runs unit-tests and builds each component using its configured compiler (for most cases, a single compiler will do for all components under the same project, for obvious reasons).I'll then export (publish) my components to Bit.dev.

'

learn-bit'

= my organization/username

'

react-demo-app

' = my component collection (scope) on Bit.dev

I'll then go over to Bit's playground, inspect my components there and add examples for them.

My team can now easily find my reusable components, see their documentation, inspect them and install them in their project as a packages using NPM/Yarn.Each component can also be imported or cloned to other projects. That means you get source-code and can even change it and push it back to Bit.dev with a bumped version.

Delivering intelligible updates - Easier maintenance

Picture this: you're responsible for the content and marketing pages in your organization's many apps and websites. You've built a whole lot of components for that. Each of them is published and available to all. Each is used multiple times, in and across projects. Now it is time for an update in one of your component. So, you do your thing, change it, and export it back to Bit.dev.Once you've published your updated component three main things happen:

Updates to documentation and live playground

Your collection in Bit.dev is updated. Changes can be seen in Bit.dev's live playground. That's not only a way to let others see the changes but also a way to test if your example still works. It could be that Bit.dev is no longer able to render your component using the previous example - and that tells you it may not work in other projects.

Automated (intelligible) PRs to all connected repositories

An automated PR is sent to all connected/consuming repositories using BitDevBot, Bit.dev's Github bot. And, as mentioned earlier, this PR is intelligible - a component that does X has changed - its clear now what could change in each project and what could possibly break.

Now that you've released this update you can keep track of where it's in use, where it's been updated and where it is still pending.().

Slack notifications - Notifying on changes to features, not 'lines'

Delivering changes as components makes it easy to notify your team of changes in a more abstract way. A change to a component is easily understood, it means a certain feature has been changed. Delivering changes as components makes it easy to notify your team of changes in a more abstract way. A change to a component is easily understood, it means a certain feature has been changed. Delivering changes as components makes it easy to notify your team of changes in a more abstract way. A change to a component is easily understood, it means a certain feature has been changed. Bit.dev integrates with Slack to do exactly that. It makes use of this abstract level to communicate to other developers, designers, product managers, etc., that a certain feature has been changed. Notified stakeholders could then examine it as part of a project or independently, in Bit.dev's playground. ().

Conclusion

As I’ve hopefully managed to demonstrate component-driven collaboration is a sure way to a more effective collaboration. It makes code more comprehensible, predictable and maintainable. It speaks a more abstract language, one that is more concise and efficient.## Related posts//blog.bitsrc.io/building-a-react-design-system-for-adoption-and-scale-1d34538619d1