WePY调研

目前为初步调研结果，并未真正使用 WePY 进行大规模开发。

初步结论

可能的疑惑

• 并不能做到在一处编写，build 之后在 vue 和小程序中都生效，而是开发出来的就只是小程序的项目(目前把项目生成web有预览版，还没有文档，目前应该只是测试)
• WePY 框架参考了 Vue 等现有框架的一些语法风格和功能特性，对原生小程序的开发模式进行了再次封装，更贴近于 MVVM 架构模式
• 由于风格相近，在 vue 中写好代码后能更容易地移植到小程序项目中
• 由于风格相近，在 WePY 中写好小程序代码后能更容易地移植到 vue 项目中

迁移成本

• 普通页替换：应该比较顺利，其中比较耗时的可能是 css 替换以及事件回调函数处理
• 模块化：WePY 有自己的模块化方案，比较耗时的应该是联调
• 国际化：看如何和现有的国际化方案结合，比较耗时的应该是前期调研和后期填坑

优势

短期来说，把代码改为使用 WePY 是需要额外的开发的，但是从长期来说，感觉还是利大于弊。

解决痛点

• css
• 事件回调函数传参
• 把一套页面的多个文件糅合进一个 .wpy 文件中
• 支持 npm 引入库
• 引入组件化开发方式，组件代替模板和模块
• 改变事件绑定方式

比如在之前开发的 H5 教师遥控器的基础上开发小程序版本的过程中，h5 中使用的是 scss 的嵌套的css写法，而小程序只能接受普通的 css 写法，人工转换是很麻烦的。

另外小程序绑定函数不支持传参，只能使用 dataset。

不需要一个 page 必须的 4个文件了（在 build 之后的 dist 中，不需要手动生成），简化了目录结构。

另外之前引入库只能手动复制代码到项目中。

简单易用，文档清晰

• 类vue的开发风格，Style template js写到一起
• 基本都是通过类继承的方式继承 WePY 上的 app page component 等父类去创建，代码结构清晰
• 有越来越多的 compiler plugin ,比如支持pug（jade）编译
• 支持mixins 有利于小程序的模块化

注意事项

虽然在很大程度上解决了小程序和 vue 风格差异较大的问题，但是还是和 vue 不是一模一样的，在具体开发的时候还是需要脑子转换思维。

• 标签还是要注意，比如小程序使用 view
• 事件绑定函数不一样，如@tap.stop
• 组件被调用时，名字使用规则和vue不一样
• 模板数据
• rem 和 rpx
• 用Repeat, 不用 wx:for
• 建议开发者工具只是用来查看效果了，不用自己生成page文件了
• 国际化（待定）

进阶

todo...