Bit VS vitro

Our demo solution was built using Bit, which allows us to create shareable components, render component “previews,” generate component docs, and so on.

UI libraries come with their own set of challenges, which greatly limit their effectiveness. These challenges stem from more fundamental problems related to code sharing and reuse. Let’s explore some of these challenges and examine how a new entity, the Bit component, addresses them.

The following diagram showcases how bit shows the dependency graph of modified components and their dependents.

This tutorial demonstrates how to build a micro frontend application using Vite and Bit.

Bit: A next-generation build system for composable software.

Bit drives a paradigm shift in the way we structure our software and collaborate on code. Its component-based approach produces more maintainable projects and more effective collaboration. However, the power of Bit is best harnessed when you adopt a certain mindset. This blog aims to guide you through the core principles and methodologies of building software with independent Bit components.

And one such tool that I've found that supports this component-driven approach is Bit.

This blog will explain how Bit can be used to implement any architecture and transform “fatal” decisions that seem too hard to change into decisions that are easy to make and change.

Oh can I address theses issues. I already looked at tools like Nx or Bit, but they aren't matching our needs with closed source libs.

To begin, you need to prepare your environment. A few ways to build a React package include tools like Bit, Storybook, Lerna, and TSDX. However, for this tutorial, you will use a zero-configuration bundler for tiny modules called Microbundle.

check out this one https://github.com/remorses/vitro

I’ve used storybook for 4 years in teams of 1-15 devs and I’d say it’s a must have for any serious react app with 3+ full time developers. It has its rough edges sure but the ROI is 10x nonetheless in my experiences.

Advantages

- Testing components in isolation forces some good practices and allows to keep the codebase in check by encouraging good practices (limited coupling of unrelated parts of the codebase

- It’s super productive because it is both a form of unit tests, useful during development of UX in « TDD mode », and a very good documentation of your UI components. It greatly reduces the effort needed for both these aspects.

- For DX, the hot reload is generally faster in storybook than in the App (except if you use vite/snowpack in your app, so far..) because reloading a single component is faster than reloading the whole app and its state. In a large CRA our hot reload could sometimes take up 1min in complex cases, while storybook was taking 3s.

- Coupled with Chromatic (their hosted platform) and its GitHub integration it makes QA and visual regression testing a joy, 10x faster than alternatives, I really recommend that.

- It allows to share/iterate easily your ongoing developments with non-tech people in your organisation at early stage. A very good bridge between Figma and the final UI. A good support during Daily meetings about UI, just shared the deployed story url to ask for feedback.

Drawbacks

- It has its own Webpack config. So if you have a custom Webpack config in your app (don’t do that anyway, unless absolutely necessary) then be prepared to duplicate the customizations in your storybook config

- Global React Contexts needs to be duplicated in your storybook config and, if necessary, configured for individual stories. For example if your signup button changes based on an Auth status stored in a global context, then you will have to use Story.parameters to customize the content of the Auth context.

- We had a couple instances where storybook was the limiting factor for us to embrace some new/fancy tech, like yarn v2 or service worker. However maybe that’s a good litmus test: things that storybook support are state of the art JS and generally safe to use. Things that storybook does not support out of the box will cause you problems with other tools anyway: if it’s not storybook, some other tool like Cypress, Jest, Next, or some browsers will cause you trouble with your “shiny new tech”

- It can be slow to startup. We had a storybook with 300+ complex stories and it took 5min to startup and 10min to build in the CI

- It had some API changes/ migration pains a couple years back. However I think the new API is very good and will last a long time so this is behind.

Overall I definitely advocate to use storybook, especially with Chromatic, the ROI is 10x. If you find yourself limited by it in 2021 despite configuring it, maybe question your own tech stack.

Don’t try to implement your own storybook copycat (we had a colleague develop an alternative https://github.com/remorses/vitro , but i think it was not worth the effort)

If you want to see a state of the art repo in NextJS that uses storybook extensively with some customizations, check https://github.com/Labelflow/labelflow/