Bit Components: Build Time and Runtime Consumption
Throughout our documentation and blog posts, you'll often encounter the term "independent components." We designed Bit components to be self-sufficient, allowing them to serve as dependencies for other components or be maintained in any workspace.
As part of the release process, Bit components generate a standard node package. Typically, other Bit components or monolithic projects consume Bit components as regular node packages during the build phase. However, in certain situations, you might want to use a Bit component at runtime. You can achieve this by converting your component into an "app component".
An app component is simply a component with an additional build task in its build pipeline - the task of deploying the component to a remote server. Once deployed, you can consume the component "over-the-wire" during runtime, not just during build time.
note
This blog post focuses on UI components and Micro Frontends (MFEs) but the principles apply to other types of Bit components as well (Node, MDX, etc.). The main purpose of this post is to clarify that the developer has the choice of how and when to consume a component.
Build Time Consumption of Bit Components
When you snap a component, Bit runs the build pipeline and generates a new version of the component. The build pipeline contains various tasks such as testing, linting, and building the component. Finally, Bit creates a package, allowing other components (or even monolithic apps) to consume it.
Auto-tagging ensures that when a component is modified and snapped, Bit automatically updates dependent components to maintain current dependencies.
In the following dependency graph, you can see how changes in the mf-remote-env propagate to the mf-remote-app and then to the host-app-build-time component:
What you don't see is the host-app consuming the mf-remote-app component. This is because the host-app component consumes the remote-app at runtime.
Maintaining Dependencies Between Runtime-Consumed Components
You can easily maintain dependencies between runtime-consumed components by creating a composition of the runtime integration in the host-app. This way, Bit will auto-tag the host-app whenever you modify and tag the remote-app. Talking about compositions, they're a great way to test your runtime integration before deploying it to production.
For runtime consumption of Bit components, you can employ various methods like module federation, single-spa, and UMD . These methods require creating an app component for deploying the code for runtime use. This approach allows for rapid reflection of changes but has the drawback of being difficult to 'save' different integration states for potential rollbacks.
Here's a remote-app component, bundled using module federation, and deployed to Netlify:
You can consume this component by a host app at runtime. For example, have a look at the host-app component:
But since Bit creates a package for each component, you can also consume the remote app during build time. You can do this by importing the remote app component into the host app component (after you install it in your Workspace). Here's another host-app component, consuming the remote app during build time:
Host App Build Time
We export the remote app implementation from the main file (index.ts), making it available for build time consumption using regular import statements:
import { MarsWeather } from '@learnbit-react/module-federation.apps.remote-app';
Every time we release a new version of the remote app, the host app (build-time) will automatically update its dependency to the latest version and release a new version of the host app.
Summary
Bit components are independent modules that you can use during build time or runtime. While build-time consumption ensures up-to-date dependencies and auto-tagging, runtime consumption allows for quicker reflection of changes.
Both methods have their advantages and disadvantages, and the choice depends on the specific requirements of a project. When selecting the appropriate method for your project, consider factors such as deployment speed, ease of maintenance, and the need for preserving previous states. By carefully evaluating these factors, you can make an informed decision that best suits your project's needs.
Bit components provide developers with the flexibility to choose how and when to consume components, based on their project requirements. Whether you opt for build-time or runtime consumption, Bit components offer a powerful and flexible solution for managing and integrating components in your applications.
