You basically have two choices on this topic. Or use a framework like React, Angular, or Vue. The advantage is that you can enjoy all the ready-made structure and advantages of a mature framework. Alternatively, you can choose Web components and their toolchains (Stencil, etc.), which have the advantage of being framework-independent and making it easier to reuse and leverage components in projects based on different frameworks.

You have to figure out which architecture works best for you. To avoid the overhead of putting each component you develop into a separate repository, many teams choose to group multiple components into many component libraries.

Tools like Bit allow you to develop, build, and test individual components of your library in complete isolation. With Bit, you can track every component in any repository (and library) as a separate unit and automatically package it with all dependencies. These components can then be independently linked to a compiler (requiring zero configuration), which can then be built, tested, and rendered independently. You can then version and publish multiple components from the repository. When you update a single component, the Bit “knows” which other components depend on that component and helps you update all components affected by that component’s update. It also provides additional “monorepo-like” features that are very conducive to code sharing, such as automatic local linking, multi-component configuration control, subset and incremental builds, circular dependency handling, dynamic workspaces, and single NPM installations.

Another option is to refactor all projects into a monorePO, but this is a huge undertaking that requires much more than just sharing code. You can also version and publish components from the repository using other helper tools (such as Lerna), but most require extensive refactoring and configuration and have no control over component dependency diagrams.

The work is far from over when components are released. You have to make sure that people can actually find, use, and update these components. Otherwise, all your hard work could be for nothing. Most people don’t bother to find your components and don’t use components that can’t be adjusted when they need to be modified. Having to dive into the entire library and update it for just one component can be a cumbersome process.

Create the component portal in bit.dev

To make your shared components available to everyone and to simplify the process of discovering and using components, you can create your own component portal or use a cloud-based portal (such as bit.dev).

  • Look for components that your team shares.
  • Learn about their apis and run live rendering examples.
  • Get a single component for use in different projects.

  • Ideally, you run builds and tests for each component.

If you decide to build your own, that’s fine, but it might take a little more time. If you choose Bit.dev, all of these features are already available, along with the ability to manage permissions and control workflow. It will host your components, run their CI, let you save and run the rendered code samples, extract the API documentation for the components, and then install them using NPM/YARN.

Bit.dev — Find, learn, try, and install components

You can take advantage of Bit for version control and publish individual components from the repository, or even multiple components in batches.

When you change a component, Bit lets you update only the component itself and other components that depend on it in the repository, so you don’t have to deal with the entire library. In this way, consumers of these components can get updates only for the components they install (and their dependencies) without having to introduce redundant updates for the entire library.

When you publish components to bit.dev, you can do more than just install them as packages. You can bit import the actual source code of the component into whatever repository you are using. There is no context switch, and you don’t have to go back to the release library to suggest your changes.

A “clone” version of this component comes with all related files and dependencies, and a linked compiler, and is versioned and managed by Bit. So you can just edit the code and run the build and test separately.

When you’re happy with the result, just bit tag a new version and export it back to bit.dev. These changes can then be updated to any other project, including the original release repository, and you can use Git in the repository to merge the changes so that component changes can be easily synchronized across all locations.

When you build and share components, you are actually building a UI component design system. This system standardizes your development efforts and shapes a consistent and comfortable visual and functional experience for your application users.

You’re not just building a library, you’re building a vibrant ecosystem of components within your organization. What you get is not just a static documentation site, but a component hub with visual rendering components, where everyone can easily find, view, and use the components you build.

UI component design system: build, distribute, apply

With Bit. dev, you can render and visualize actual code components (React, Vue, Angular) to help developers and designers understand exactly how their components look, behave, and experience to users. They can even run the components on an editable presentation desk at any time.

Here, developers can easily find and install the components they need, and they and designers can also see the visualizations of the components. When a developer makes a change and updates the version of a particular component, designers can immediately view the new version and monitor the changes to ensure that the generated component is appropriate for their design system.

There is a good balance between developers having the flexibility to make changes to components as needed and submitting update proposals through their own projects, while designers can join in collaboration to review changes at any time.

With Bit, you can build, package, and publish components separately in a library. You can then export them to Bit.dev to build a visual design system made up of actual source code components.

  • Modular component development: By automatically encapsulating components and all their dependencies in a repository, and then linking to a compiler with zero configuration, you can easily build, test, and update components and their dependencies in the repository without affecting the rest of the world. You can then batch publish the components, each as a separate package.
  • Simplify component discovery and use: Integrate components into a portal to make it easy for everyone to discover and use them. Easily update and control changes across projects.

  • Improve component usage and collaboration: Allow yourself and your team partners to propose changes to components directly in your own projects, making PR in complex libraries without context switching. Increases component adoption and utilization, reduces copy and paste, and improves UI standardization and consistency across applications and screens.

Reusing components across multiple projects and repositories creates an efficient component economy between projects and team members. Whether you’re using libraries or sharing components directly between projects, three principles remain the same: develop components as reusable units; Distribute them for everyone to find and use; Get yourself and others to adopt these components and collaborate on changes.

Please feel free to check out the Bit’s GitHub link for any questions, comments or feedback. Wish you all the best in your component development! 🐥

Bit：https://github.com/teambit/bit

English text: https://itnext.io/how-to-easily-reuse-components-across-projects-and-repositories-fa73f8ba2a83