Using Bit.dev (Bit Harmony) for React Native Component management and versioning

In this guide, I will show how to use Bit Harmony to manage versions, and reuse the components of an existing React Native project.

Previously, in the guide "Introduction to Bit.dev (Bit Harmony) to manage our React Native components" I already explained how to install and configure Bit for React Native projects. I will start from an existing project where I have already programmed several components, but where Bit has not been configured yet, this is probably the case for most people, and also the most complicated to implement.

As I have said before, in this guide I will use as an example an existing project called "savver" which consists of a React Native application programmed with TypeScript. To initialize this project, I used the react-native-community / react-native-template-typescript template: 👾 Clean and minimalist React Native template for a quick start with TypeScript. (Github.com)

Therefore, the project structure is completely based on this template.

Structure of the project folders

First of all, we have the root folder "savver" that contains all the configuration files, the modules folder, the src folder, the App.tsx file, and the index.js file

The src folder only contains three folders:

• Components: Contains all the custom components that I have implemented for the application, these are organized in folders with their names, where within each one is the code.
• Screens: It has the folders of all the screens that I have created to form the application, within these folders is the code.
• Data: Groups the code files where all the application data management is implemented.

Custom components have been implemented specifically for savver, but can be reused in any other application.

First of all, I will carry out the initial configuration of Bit in the project, but I will summarize certain parts, because this has already been explained in the previous tutorial, anyway if there is any doubt about this you can take a look at the guide, or send me a message.

Initialization

To start with the configuration, the command bit init --harmony to initialize the Bit workspace in the project is executed in the root folder of the savver project.

brandre of the project in workspace.jsonc, but in my case, I will not create a new remote scope in the Bit.dev user, since in this project I will configure as defaultScope, the scope "test" that I already had previously created. In this way, the components will be exported to this same scope.

Therefore, in the workspace.jsonc file, you have to edit the defaultScope property following the expression “<username>. <Scope name>” so in my project, the property is set as follows:

"defaultScope": "brandres.test"

Further down in the workspace.jsonc file, set the property "teambit.workspace/variants" as specified below:

It can be seen that in "teambit.dependencies/dependency-resolver" in the peerDependencies policy, the version of react that is specified in package.json must be set as a dependency of all the components, since this version is the one we have installed in the project, and it is the one used to develop the components. Specifying this is very important since by default Bit uses other dependency policies that can cause problems when installing the component in other projects using npm ≥ 7

In my case, I use version 17.0.1 and therefore in my configuration, it would be the following:

"teambit.dependencies/dependency-resolver": {
  "policy": {
    "peerDependencies": {
      "react": "17.0.1",
      "react-dom": "17.0.1"
    }
  }
}

Adding components

In my situation, I am not going to create any new components, I am only going to add the existing components. To do this, there are two options:

• Add them one by one with the command:

bit add <component path> -n <component namespace>

• Add several using the command:

bit add <path of the folder containing the components/*> -n <component namespace>

I have chosen to add the components one by one since in the components folder there are some components that I am not going to add since they are specific to the application, and it does not make sense to use them in others. Also, I am not going to group the components in a namespace, therefore I will not use the -n flag to specify the name.

Result after adding the components

If you had decided to export all the components in the components folder, you should have executed the following command:

bit add src/components/*

At this point, the components have already been added to Bit's workspace, so they can be viewed on the development server. To do this, the following commands must be executed in the same order:

bit compile
bit start

The output of compile command execution

The output of the start command execution

If everything has gone well, you will be able to visualize all the components that have been added previously in http://localhost: 3000/.

Regarding the example that I have carried out during this guide, the following could be observed:

Viewing the added components

Exporting components

Before exporting the added components, we have to tag them using the bit tag command. This will create a new version of each component but for this, we have two options:

• Label each component one by one with the command:

bit tag <componentID> --patch --message "first version"

• Label all components at once using the following command:

bit tag --all --message "first version"

In my case, I have opted for the second option since I label all the components that I have previously added at the same time with a command. The execution of the command bit tag --all --message “first version” and its output can be seen below:

Sometimes errors can appear when executing this command, in my case I have a dependency error caused because this component imports a type from the type file of the same project. We can solve this error in two ways:

• Adding the dependent element to the workspace using the command bit add
• Refactoring the code so that it is not dependent on this element.

I have chosen to refactor the code of the Dropdown component which depends on the StorageItem type. To do this, I have removed the import of the StorageItem type and specified the type directly in the component. In this way, the type is self-contained in the component, which simplifies the component's reuse, management, and maintenance.

This refactoring of the Dropdown can be seen below:

Now the definition of the component's props has to specify the structure of the type:

Finally, it would only be necessary to change the places where the types were used:

After solving the errors, you have to run the command again bit tag --all --message “first version” and if everything has gone correctly the components should be labelled, as can be seen in my case after executing this command:

After this you have to export the components using the following command:

bit export

After exporting the components, I am shown the following message:

That means it went well and, in your case, it should be something similar but with your components.

After this, the components would already be published correctly in the remote scope of our user, and would be accessible through https://bit.dev/<user-name>/<scope-name>, which in my case is https: // bit.dev/brandres/test where you can see the following:

You will see something similar, but with your components. On this page you can access the details of each component by clicking on its card, these details are auto-generated with the component's code, but much more information about the component can be added through its spec, compositions, and docs files, I will explain this in future guides.

Using published components

Finally, it would only be necessary to reuse the components in other projects, for this you simply have to access the detail of the component through https://bit.dev/<user-name>/<scope-name> or https: //bit. dev /<user-name>/<scope-name>/<component-name>

In this component detail, there is a " Use" button that shows the npm, bit, or yarn commands to install the component. This can be seen below in my example of the DropDown component:

To test the import/installation of the components in other projects, I have created a React Native project with a bit initialized workspace, as I show in the configuration guide.

As you can see, we have two options:

• Import the component by bit, this creates a folder in the workspace that contains the component, in the same way as in the previous workspace, this component can be edited and managed from the new workspace by bit, so you can export new versions of the component, and at the same time use it in the new project. For this, it is necessary to have initialized the Bit workspace where the component will be imported.
• Install the component through npm or yarn, which installs it as a dependency of the project, as if it were another package that we install in the project. In this case, it is not necessary to initialize the bit workspace, so it is much more convenient if you are not going to edit or manage the component.

I'm going to try to install the component through npm, for this the first thing to do is configure the user as a scope registry using the following command:

npm config set '@YourUserName:registry' https://node.bit.dev

In my case this command is:

npm config set '@brandres: registry' https://node.bit.dev

Afterwards, the installation of the components can be carried out using the command:

npm install @YourUserName/componentScopeName.componentID

In my example, to install the DropDown component it would be the following command:

npm install @brandres/test.drop-down

Finally, it would only be necessary to import and use the component, for this you simply have to import it in the code:

import { Component } from ‘@yourUserName/componentScopeName.componentID’;

Following this fragment, my DropDown component would be imported as follows:

import DropDown from ‘@brandres/test.drop-down’;

After this, you can use the component in the new project like the other components.

I hope this text has been helpful in your applications and components. Surely do more guides on how to use other interesting aspects of bit, such as documentation or compositions. I also think that creating a Bit workspace within a React Native project is not the best idea. I have several proposals on how to solve this, but without a doubt, they are much more difficult to carry out than everything I have just explained, but later I will surely write an entire guide dedicated to this topic.

If you have any doubt or suggestions you can comment to me without any problem😉.

Thank you very much.

Introduction to Bit Harmony:

Introduction to Bit.dev (Bit Harmony) for managing our React Native components