This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
Creating a Modular, Extensible, and Dynamic UI library That’s Built To Last
A well-crafted UI library is flexible, and this flexibility should manifest itself when the library is consumed, extended, or modified.
As is often the case in software development, flexibility is achieved by constructing composable software that consists of loosely coupled and interoperable components.
For example, see this custom Material UI library. Components in this library can be consumed individually; they are versioned individually, documented individually, and can even be maintained as individual pieces in any project that consumes them.
In this demo, components can be consumed from Bit’s registry, NPM registry, and even ESM registries like esm.sh (for consumption in runtime):
Bit Scope:
Git Repo:
Building highly modular UI component libraries
Building a UI library that consists of small independent componetns or packages can become quite a nightmare, as each package requires its own package.json configuration, which might include third-party dependencies as well as “internal dependencies” from the same project, the same UI library.
The “mega library” alternative
A common alternative is building a single “mega library.” This simplifies maintenance as you not only have just a single package.json to maintain but also a single build and versioning for the entire collection of your UI components.
However, this approach does not meet our requirements. Instead of multiple small decoupled codebases, you have a large codebase with tightly coupled components. This makes the library more fragile, harder to maintain and debug, and less likely to grow and respond to new requirements.
Going for the gold standard using proper tooling
Using Bit, you are relieved from the burden of manually configuring each component. Instead, Bit auto-detects your component’s dependencies and intelligently resolves their types and versions.
When a package is generated, the detected dependencies are included in its package.json .
How to Create and Publish NPM Packages
Bit also builds and versions each module in the right order. For example, let’s say icon-button@0.0.1 depends on button@0.0.2 . Bit auto-detects this dependency and includes it in the icon-button package.json.
What happens if button is modified? Bit will run the build for button , bump its version to 0.0.3 and automatically run the build for icon-button which now includes in its package.json the newer version of button - button@0.0.3 .
How can users suggest changes to the UI library?
Bit components can be maintained and updated as isolated units of code. No need to switch to another repository and go through the thicks of a new codebase. You can fetch the component you wish to modify into your repo, make changes, and push the change requests for the UI library maintainer to review and merge. This sort of collaboration between teams in the same enterprise is known as “InnerSource”.
As mentioned, providing potential contributors with small and simple codebases rather than one large complex codebase guarantees more contributions.
OpenSource to InnerSource: Why Enterprises are Adopting this Strategy
Learn more
- How to Create and Publish NPM Packages
- Crafting a Community-Driven UI Library: A Guide to Fostering Collaboration and Adoption
Building a UI Library for Your Micro Frontends and Apps was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
Eden Ella | Sciencx (2024-06-26T10:10:40+00:00) Building a UI Library for Your Micro Frontends and Apps. Retrieved from https://www.scien.cx/2024/06/26/building-a-ui-library-for-your-micro-frontends-and-apps/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.