How do native RN programs and Taro coexist?

Our team started to practice the React Native project, and for a long time,

All business modules are developed and maintained in one project, which becomes a big project over time.

In addition to the introduction of AN RN program based on Taro, in order to ensure the coexistence of native and Taro RNS,

The main exported index file format is the same for both native RN and Taro projects’ package.json files.

We use the following scheme to maintain our code.

Use NPM to manage our business modules

The main project of RN business

This is my initial practice. First we create a main project of RN.

There is no business code in it, only an index.js business index file in the root directory.

It looks something like this:


import { AppRegistry} from 'react-native';
import Module1 from 'Module1';
import Module2 from 'Module2';
import Module3 from 'Module3';
AppRegistry.registerComponent('Module1'.() = > Module1);
AppRegistry.registerComponent('Module2'.() = > Module2);
AppRegistry.registerComponent('Module3'.() = > Module3);
Copy the code

As I mentioned in a previous article, all of our module dependencies are uniform and version-locked.

Interested can click to view:

Taro provides dependency management for cross-end development

So my main project’s dependencies are consistent with the business module’s dependencies.

Use NPM to manage business modules

We will manage all business modules as NPM because NPM has many lifecycle hooks.

After unifying NPM script commands, it is easy to unify them.

Of course we do not publish these business modules to the NPM server, because the business code changes frequently, and if every commit is uploaded to the NPM server, it will naturally add the code management cost of the developer (publishing the NPM package is annoying).

So we use NPM + git address to pull our business module.

Such as:

Package. json for the main project


{
"name": "base"."version": "0.0.6"."scripts": {
"build":"Operations related to building RN."
},
"dependencies": {
"Public dependency packages": "1.0.0"."Module1": "http://xxx.com/webfront/Module1.git"."Module2": "http://xxx.com/webfront/Module2.git"."Module3": "http://xxx.com/webfront/Module3.git",}}Copy the code

Package. json for the business module

Postinstall is added to the business module. After pulling the business module successfully using NPM, the business module will build its own project in node_modules, providing index.js for the main project

{
"name": "buz"."version": "0.0.1"."main": "main.js".The main field should point to an index file of RN
"scripts": {
"build":"Operations related to building RN."."postinstall":"npm run build"
},
"dependencies": {
"Public dependency packages": "1.0.0"}}Copy the code

Unified output main.js file


"use strict";

// Determine whether to export any file according to the environment variable of the end

if (process.env.TARO_ENV === 'weapp' || process.env.TARO_ENV === 'h5') {
module.exports = require('./dist/index');
module.exports.default = module.exports
} else {
// Taro department of engineering, standard external output
Object.defineProperty(exports."__esModule", {
value: true
});
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
var _app = _interopRequireDefault(require("./rn_temp/app"));
exports.APP = _app.default;
}

Copy the code

Business modules debug each other

There will certainly be intermodulation between businesses, the above solution business module can only run its own code, when we want to jump to another RN page, that is not possible.

In fact, we can make all the business modules as the main module, during the development and debugging of all business modules.

This way all business code can run, except that other business modules are placed in node_modules and cannot modify the code.

The advantages and disadvantages of the scheme

The program recommends medium-size project recommendations

Advantages:

  1. Native RN can coexist with Taro, and as long as the exported main specification is consistent, the main project can be registered as a unified module

  2. All business modules are maintained separately to avoid the production of big projects

  3. Businesses can jump from one business to another, and a single business module can pull up an entire RN project

Disadvantages:

  1. NPM installing projects can be very time consuming because not only do dependencies need to be installed, but business modules also build projects at Postinstall time.

  2. NPM install must be re-installed after the business module is updated

The tail

The solution is for rn projects of medium size, if you’re like me and you’re developing dozens of business modules at the same time. It’s going to be even more challenging.

In the following articles, I will introduce the ultimate management method of RN terminal based on Taro.

It will also solve all of the shortcomings mentioned above.