晚上圆桌会议关于 Weex 组件方向讨论总结
- 通用性,只有多个业务同时在使用,同时具有可抽离性特性的组件,譬如Video/TabBar/TitleBar/ImageUpload 这些在 Native中成熟的组件
- 稳定性,Native 组件不像 weex 上层的组件可调节性大,因此须要注意好 Native 组件必定须要没有Bug,防止修复和更新麻烦,同时 Native 组件一开始应该将大部分状况作成可配置化,防止频繁更新,致使须要适配不少版本
- 原子性,不建议一个组件同时作不少事情,应该是单一的功能,而后经过搭配的方式来获得更多功能
- 811原则,默认80%的功能应该是不须要用户配置不少参数,10%的地方用户能够经过配置一些参数来达到目的,10%的稀有状况能够暂时不考虑,可能这里会花费不少时间开发,因此能够等到有业务须要使用时候,再更新上去
- 统一收口原则,为了不后续组件变成一个大杂烩,后续迭代视觉交互、新功能的增长须要将通用性考虑进去,这里须要一我的统一来收口、开发维护此组件,能够避免不少“业务特性”来干扰组件的可用性
- 性能体验的优化,Weex 组件比页面的编写更应该保证他的性能体验
- 信任机制:不少时候别人使用你的组件一个很大缘由是因为相信你的组件没有问题,是稳定的,同时后续会经常维护的
- 缺乏一些聚集起来使用的场景,目前单个组件的使用文档已经详细说明,可是对于多个组件的一些使用,或者页面层面的开发缺乏相关案例,后期须要逐步补上weex-ui-demo
- 主题配置灵活性上须要考虑进行,目前更可能是经过参数配置的方式来更改主题颜色,实际上是能够经过一个统一外部参数的配置来使它修改
- Native的布局方式须要向H5的开发灵活性学习,逐步使用自动布局来实现,同时引入弹性思路开发,避免绝对计算
- 数据绑定方面会愈来愈便捷,譬如和MVVM思路同样,数据变化后,视图立马修改,而不是手动去触发
欢迎关注本站公众号,获取更多信息