介绍

前端频道和JD凸实验室已经在塔罗项目上达成了开源合作，并大规模重建了Taro 3支持解决方案。

经过长期讨论该计划，RFC提案已正式向公众宣布，并提出了社区意见。开源社区参与者可以通过单击或单击原始文本来参加提案讨论，并期待您的参与。

提案详细信息

概述

在芋头实施使用率开发。

动机

将塔罗升级到3后，无法使用它，社区仍然需要使用塔罗发展。

用例

在页面组件和自定义组件的开发中，遵循与编写项目相同的规格。

输入组件生命周期，页面组件生命周期和页面事件处理功能的支持水平与小程序的支持水平不同。请参阅详细的设计运行时部分。

与API和组件支持相比，有一些权衡。请参阅API和组件零件的详细设计。

详细的设计

该提案基于塔罗3中定义的标准，并完成了终点的升级和转换。同时，它在编译和包装解决方案，API和组件支持以及项目访问灵活性方面进行了重大重建。

设计摘要

统一编译和包装解决方案，使其更符合生态系统。

与 +方法相比，它可以提高汇编速度，并且整体解决方案更清晰。

与多模相比，可以减小数据包大小。同时解决多模式中的一些问题，例如＃7512。

提供更好的支持并优化开发经验。

它可以灵活地与App项目自己的配置（例如分包）合并。

根据Taro 3中定义的标准对运行时模块进行修改。

它基本上与小程序和H5的写作方法一致。输入和页面代码是生成（类似于塔罗），并且通过TARO-RN软件包提供的方法包装了输入组件和页面组件。

提高对页面事件处理功能的支持。

添加了与Tab Bar相关的API的封装。

改善API和组件的支持。

支持是基于社区调查结果的优先级和难度，而博览会系统仍然是主要重点。

API和组件可以按需集成，为本机API和组件的依赖项提供完整的本机集成文档。

取决于工作量，逐渐增加支持并欢迎社区贡献。

提供更灵活的应用程序访问解决方案。

该版本不再锁定。用户可以在项目中安装> = 0.60版本。对于> = 0.57 && = 0.60版本，默认情况下将选择最新的稳定版本。用户可以根据需要选择要安装的兼容版本。同时， 或其自己的应用需要相应的版本。

不要强制取决于一切

当应用程序中某些API不存在时，某些API是不可用的，并且警告会弹出而不是阻止操作。

其他

状态管理支持

用户应处理相同的TARO 3解决方案。

分包合同

尚不支持分包合同，并且将合并到其中的分包合同。

壳工程

留在原始项目仓库塔罗（Taro）中，添加新的分支0.63.0、0.62.0、0.61.0和0.60.0，所有分支都对应于Taro 3版本。

缺点

0。不支持使用VUE或框架写作。

1。总体设计与小程序和H5有些不同。

2。采用了汇编和包装方案，这与该计划大不相同。新版本迭代的更新需要及时同步，以支持一些新的写作方法。

适应策略

0。使用芋头开发的代码与不支持的组件和接口兼容。安装相应的依赖项后，它可以在环境中运行。

1。包含一些本地依赖性，需要添加到其各自的本机仓库中或用于外壳项目中。

2。实现的样式是CSS的子集，不能完全兼容。该业务需要与跨端项目建议兼容。

作者资料：

Chen ：前端建筑师和技术委员会成员。