2018-11-19

组件库 weex-ui

Weex 原生组件的封装应该注意什么？

1. 通用性，只有多个业务同时在使用，同时具备可抽离性特性的组件，譬如Video/TabBar/TitleBar/ImageUpload 这些在 Native中成熟的组件

2. 稳定性，Native 组件不像 weex 上层的组件可调节性大，所以需要注意好 Native 组件一定需要没有Bug，防止修复和更新麻烦，同时 Native 组件一开始应该将大部分情况做成可配置化，防止频繁更新，导致需要适配很多版本

3. 原子性，不建议一个组件同时做很多事情，应该是单一的功能，然后通过搭配的方式来得到更多功能

weex 组件开发和实践过程中的一些经验？

1. 811原则，默认80%的功能应该是不需要用户配置很多参数，10%的地方用户可以通过配置一些参数来达到目的，10%的稀有情况可以暂时不考虑，可能这里会花费很多时间开发，所以可以等到有业务需要使用时候，再更新上去

2. 统一收口原则，为了避免后续组件变成一个大杂烩，后续迭代视觉交互、新功能的增加需要将通用性考虑进去，这里需要一个人统一来收口、开发维护此组件，可以避免很多“业务特性”来干扰组件的可用性

3. 性能体验的优化，Weex 组件比页面的编写更应该保证他的性能体验

4. 信任机制：很多时候别人使用你的组件一个很大原因是由于相信你的组件没有问题，是稳定的，同时后续会常常维护的

升级场景

1. 能升级，且能升级到最新版

2. 无需升级,已经是最新版本

3. 能升级,能升级到当前appMinV的最新bundle版本,但不是最新的bundle,想升最新bundle，必须先升app

4. 不能升级,已经是当前appMinV的最新bundle,但不是最新的bundle,想升最新bundle，必须先升app

跳转规则

Native 渲染weex页面的时候，需要传入构建出来的js bundle，即一个js文件。但是，不管是Native的日常写法还是前端的惯常用法，都不会直接跳转到一个js文件。所以，考虑到符合前端的日常写法，跳转时，统一跳转到url，如下图：

不管是weex，native，webview里的跳转都是url，然后再根据一定的规则进行match，根据match结果来决定是用weex、native还是webview来打开

要做到weex，native，webview里的跳转都是url，这里需要做两点：

1. 跳转需要调用统一的openUrl，weex里的a标签href直接可以写目标url，然后在Native端对a标签的跳转进行拦截；

2. webview 里的跳转进行拦截，每个url都要进行规则匹配

定义规则，App内置一份，并可以动态下发

1. url 和 原先 Native 页面的对应关系，page可以根据原先App里的Router设计来定义。

2. url 和 weex js的对应关系,hideTitleBar:是否隐藏native的titlebar;v：支持最低App版本，不支持就降级；page: 页面名称，作为本地预加载的文件名；h5: h5的url;url: js的路径；md5: js文件的md5,用于完整性校验

---