Optimizing Collaboration Between Frontend Developers
Tags: javascript, react, github, typescript
Published: 2020-03-19 16:07:31

_Dislacimer: This post explains how to use [Bit](https://bit.dev) with [Github](https://github.com) and [Slack](https://slack.com) for a more efficient workflow and better collaboration. - I am part of the [Bit](https://bit.dev) team and these are my biased opinions._

## Searching for the Right Tools and Methodologies

Maintaining effective collaboration is always a challenge but much more so in distributed teams — especially if this type of workforce model was brought on, quite suddenly and unwillingly, by the new Coronavirus.

For many organizations, the current outbreak initiated a trial run for working remotely. These new experiments have got developers hurriedly searching for the right [tools and methodologies](https://bit.dev) that would promote collaboration.

## Visualizing the Target: Effective Collaboration

When reviewing [tools and methodologies](https://bit.dev) for collaboration, it can be helpful to visualize the target — what would an effective collaboration look like?

In an effective collaboration, developers working on the same codebase never step on each other's toes; there are no “merging disasters”.

In an effective collaboration, code never gets written twice— every developer knows what’s already been written and what’s available for reuse. No time goes to waste, the codebase is clean and elegant, and new features get delivered on time.

In an effective collaboration, maintenance is simple and safe. Every piece of code is easily comprehensible. Dependencies in code are clearly manifested and outcomes of changes in code can be easily predicted.

In an effective collaboration, collaboration is not limited by the borders of a single repository. Every piece of code is available to all repos and changes to code in one repo get communicated to all relevant repositories. Consistency in UI is kept in and across projects and repositories.

## Effective Collaboration with Bit

### Augmenting Component-Driven Development (CDD)

[Bit](https://bit.dev) is a tool and a platform that augments the benefits of component-driven development.

It does that by making reusable components available to everyone in your team. It enables sharing components from any repository or codebase to one central component hub (a private registry and a documentation site). Shared components can be installed as packages using npm/yarn or ‘cloned’ as source-code, to any repository, using Bit.

[Bit](https://bit.dev/) does its magic by tracking each component’s dependencies and versioning it as a stand-alone unit of code.

![Example: Sharing components from a React project](https://cdn-images-1.medium.com/max/2000/1*_q2wbLOtoJt5lbcGSWzPFw.gif)*Example: Sharing components from a React project*

### Tracking Dependencies for a Better Predictability

Bit’s mastery of dependency graphs is not only in the service of component isolation. It can also be used as a great assistant for maintaining code, as it provides developers with a clear image of their code dependencies and by that, assists in predicting the outcome of changes in code.

![Example: A graph produced by the ‘bit graph’ utility, showing dependencies of a ‘card’ component](https://cdn-images-1.medium.com/max/2000/0*S1NXS5sb3IDncyLl)*Example: A graph produced by the ‘bit graph’ utility, showing dependencies of a ‘card’ component*

### Making Shared Components Easily Discoverable

Sharing components is only half the way to maximizing code reuse /collaboration— making them easily discoverable is the other half. Bit makes sure everybody in your organization knows which reusable components are available, which are no longer available, and which of them have been modified or updated. It does that, mainly, by presenting your team an indexed, tagged and scoped catalog of components, all of which can be rendered live.

![Example: browsing through shared components in bit.dev](https://cdn-images-1.medium.com/max/2000/1*Nj2EzGOskF51B5AKuR-szw.gif)*Example: browsing through shared components in bit.dev*

To further support communication and collaboration, Bit offers integrations with Github and Slack.

## Bit with GitHub

![](https://cdn-images-1.medium.com/max/2000/1*RZP_jNEEilVtmjGH4O4UHQ.gif)

### Importing & Merging Shared Components

As mentioned earlier, Bit’s shared components can be imported with their source code as well as their built packages. That is essential to enable component collaboration and not just the consumption of components from a single author.

It also enables you to modify imported components in your working repository without losing future updates. So, unlike “traditional” published packages, it is no longer an all-or-nothing situation — you can receive updates and merge them with your own modified version of that component. If a shared component does not meet your needs 100%, you're not forced to completely re-write your own version of it.

### Code Updates Grouped to Meaningful Units of Code

Moreover, if anything goes wrong with your app, discovering the culprit and rolling back, is much easier, as every update has semantic meaning to it. It is not only meaningless changes to code across multiple files — these are changes grouped to meaningful units of code (components) that are easy to understand and manage.

### Automated PRs to Connected/Consuming GitHub Repositories

Collaboration is determined by the clarity and efficiency of communication. To help achieve that, [Bit](https://bit.dev) has recently come out with the new *BitDevBot*, a Github bot that automates pull-requests to repositories with imported components.

![](https://cdn-images-1.medium.com/max/2000/0*6LaMRxTgoZpoYHcE.png)

Whenever a component gets updated, all relevant repositories are prompted to merge the new changes. That's a great way to ensure consumers of components never miss out on important updates.

This great combo of Bit and Github is not only a way to automate PRs but also, a way to eliminate redundant and irrelevant updates. That is one of the many benefits of sharing code on a component level and not on a larger scale (e.g., a library). That means you're only notified and prompted, on updates that matter to you.

![Component exports are translated to PRs](https://cdn-images-1.medium.com/max/2000/0*mTy3LPHM7Nah1MGK.png)*Component exports are translated to PRs*

Another great thing that “naturally” comes with automated PRs is being able to use them as triggers for your CI — so you can run tests and quickly discover if they integrate well into your codebase (and again, updates on a component level means no redundant CIs).

### Keeping Track of Who’s Using What, and Where

Another great feature of Bit’s Github integration is the ability to track who’s using which component and who’s yet updated to a newer version.

![](https://cdn-images-1.medium.com/max/2406/1*XwW4laTWW1zBZkwUPOVBtA.jpeg)

The Bot log view shows all PRs made for all components. Component authors and maintainers can track the adoption of a new component and communicate with the project managers, in case they did not apply the changes to their projects. They can also use this data to understand the effects a change to a component would have (as they know exactly where and how it is being used).

To learn more about how to use [Bit](https://bit.dev)’s Github integration — [read on here](https://blog.bitsrc.io/announcing-auto-github-prs-for-component-version-bumping-74e7768bcd8a).

## Bit with Slack

![](https://cdn-images-1.medium.com/max/2560/1*B9rlh6Xf8psI_qBE0Quk1A.jpeg)

Slack has become a staple in every developer’s toolbox, making it the right platform to notify your team or organization of “actions” made on shared components. These actions include component **exports** (when sharing a new or updated component), component **imports** (when consuming a new or updated component), and component **removals**. That’s another way to ensure your team is always up-to-date.

One great use of it (other than never missing out on a valuable shared component) becomes apparent when working in parallel with other developers. For example, you may find yourself waiting for a feature to be delivered before you can build or test your own. Getting a push notification immediately when that feature is delivered saves time otherwise wasted on bad communication (push notifications for new merges are nothing new but when code updates are delivered in units of independent code — i.e, components— it's much more intelligible, much closer to the business logic of that project and thus, much easier to base your decisions upon).

**To integrate [Bit](https://bit.dev) with Slack:**

1. You should have [an organization](https://bit.dev/~create-org)

1. You should have at least one [collection](https://bit.dev/~create-collection) (this collection has to be connected to your organization and not directly to your user)

1. Enter your organization and click on “Integrations” (on the top right corner)

1. Install the Slack integration

1. Configure your notification preferences: on which Slack channel you’d like to be notified and on what events or “actions”.

![](https://cdn-images-1.medium.com/max/2000/1*R0S2OLGAi_ER1FJFhQILfQ.png)

![](https://cdn-images-1.medium.com/max/3598/1*lnV42gsi2_lF1AgF2s2JgA.png)

So, for example, when a component gets exported, your team receives a notification that includes the user’s name, the type of action (export), the number of components related to that specific action and the target collection.

![](https://cdn-images-1.medium.com/max/2000/1*eTV477JqfbO7JvcuO2RnZw.png)

When importing, the same notification shows but with the origin collection.

![](https://cdn-images-1.medium.com/max/2000/1*0UpTx7CfLIzl56b2Nj8gSg.png)

Simple.

## Conclusion

As I’ve hopefully managed to demonstrate, component-driven design, together with Bit, is a sure way to more effective collaboration. It makes code more comprehensible, predictable and maintainable. It is a way to easily extend collaboration beyond the borders of one repository and it encourages code reuse and standardization, in and across projects.