taro 引入js_Taro 跨端开发之多业务模块管理 React Native篇(上)

本文探讨了如何在原生React Native项目中与Taro项目共存,通过使用npm管理业务模块,实现主工程与多个业务模块的协同开发。介绍了主工程的配置,业务模块的package.json设置,以及如何通过postinstall构建业务模块。该方案有利于项目拆分和独立维护,但存在npm安装耗时和模块更新需重新安装的问题。
摘要由CSDN通过智能技术生成

原生 RN 项目与 Taro 如何共存?

我们团队一开始就有实践原生 React Native 的项目,很长一段时间,

所有的业务模块都是在一个项目里面开发维护,时间久了这个项目就变成了一个巨无霸项目.

再加上后来引进了基于 Taro 开发的 RN 项目,为了保证原生与 Taro 的 RN 共存,

不管是原生 RN 项目还是 Taro 项目的 package.json 文件的 main 对外导出的索引文件格式都是一致的.

我们使用以下方案来维护我们的代码.

使用 npm 来管理我们的业务模块

RN 业务的主工程

这是我最初实践的方案,首先我们创建一个项目为 RN 的主工程.

里面没有任何的业务代码,只有在根目录下有一个 index.js 的业务索引文件.

它大概是这样的:


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);

之前的一篇文章我已经提到,我们所有的模块依赖都是统一的,并且版本锁死.

有兴趣的可以点击查看:

Taro 跨端开发之依赖管理

所以我的主工程的依赖与业务模块的依赖是保持一致的.

使用 NPM 管理业务模块

我们会把所有的业务模块当成 npm 来管理,因为 npm 有很多的生命周期钩子使用.

在统一了 npm script 命令之后,很容易统一管理他们.

当然这些业务模块我们不会把他发布到 npm 服务器上,因为业务代码会频繁变动,如果每一次提交都要上传到 npm 服务器,自然会添加开发人员的代码管理成本(发布npm包很烦的)

所以我们使用 npm + git 地址来拉取我们的业务模块.

例如:

主工程的 package.json

{
"name": "base",
"version": "0.0.6",
"scripts": {
"build":"构建rn的相关操作"
},
"dependencies": {
"公共依赖包": "1.0.0",
"Module1": "http://xxx.com/webfront/Module1.git",
"Module2": "http://xxx.com/webfront/Module2.git",
"Module3": "http://xxx.com/webfront/Module3.git",
}
}

业务模块的 package.json

业务模块添加了postinstall,在使用npm拉取业务模块成功之后,业务模块会在 node_modules 中构建自己的项目,提供主工程的index.js使用

{
"name": "buz",
"version": "0.0.1",
"main": "main.js", // main字段要指向rn的索引文件
"scripts": {
"build":"构建rn的相关操作",
"postinstall":"npm run build"
},
"dependencies": {
"公共依赖包": "1.0.0"
}
}

统一对外输出的 main.js 文件

"use strict";

// 根据端的环境变量判断是否对外输出什么文件

if (process.env.TARO_ENV === 'weapp' || process.env.TARO_ENV === 'h5') {
module.exports = require('./dist/index');
module.exports.default = module.exports
} else {
// taro系工程,标准对外输出
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;
}

业务模块之间相互调试

业务与业务之间肯定会有相互联调的情况,以上的方案业务模块只能独立运行自己的代码,当我们想要跳转到其他RN页面的时候,那就不行了.

其实我们可以让所有的业务模块跟主模块一样,在开发调试的时候引入所有的业务模块.

这样所有的业务代码都可以跑起来了,区别只在于其他业务模块放在node_modules中,不能修改代码.

该方案的优劣势

该方案建议中型的项目推荐

优点:

  1. 可以原生 RN 与 Taro 共存,只要对外导出的 main 规范一致,主工程就可以作为统一模块注册

  2. 所有业务模块单独维护,避免了项目巨无霸的产生

  3. 业务与业务之间也可以相互跳转,单独一个业务模块也可以拉起完整的rn项目

缺点:

  1. npm install 项目的时候会非常耗时,因为不单要安装依赖,业务模块也会在postinstall 的时候构建项目.

  2. 业务模块更新之后,必须要重新 npm install

尾巴

该方案面向中等大小项目的 RN 项目,要是你跟我一样几十个业务模块在同时开发.会带来更大的挑战。

后续文章我会介绍基于 Taro 的 RN 端终极管理办法。

同时也会解决以上所有的缺点。


更多文章可以关注我的博客

43079e2089ec2daac6f97a5114295778.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值