vue项目composition-api，typescript，ssr，pwa改造
这里介绍原传统vue2全家桶的项目，如何改造成vue3 composition-api+typescript+ssr服务端渲染+pwa的项目。项目使用UI库和脚手架为quasar。选择quasar原因很简单，对比了国内外一大堆UI库(vuetify、element-ui、iview等.....)之后，发现quasar前端优化做的最好，但缺点是上手难，体系庞大，前期学习成本和耗费时间较高。
一、改造前/改造后，项目结构对比：
改造前：
改造后：
项目均用quasar脚手架搭建项目，通过quasar create 创建默认项目结构。改造前项目由于采用vue2全家桶，每个页面对应一个vuex模块，每个vuex模块都由actions,mutations,getters,stats组成。
改造后项目砍掉了vuex，由于采用composition-api提供的响应式追踪api，reactive,ref..等，新版本函数高度复用，每个页面对应一个ts函数文件，listaction.ts对应每个列表页面公用函数，editaction.ts对应每个增删改页面公用函数，model.ts综合存放typescript对应用到的interface。
二、改造前后，项目结构思路
改造前：
改造前项目每个页面有自己独立的vuex，所有逻辑处理和状态变更，都在自己独立的vuex里面完成。相似功能的页面只能重复写相似功能的函数。
改造后：
改造后项目每个页面有自己独立的响应式数据，但是多个页面可以公用相同的逻辑函数，调用共同函数的时候，将页面自己独立的响应式数据传进去，由相同的函数去修改每个页面不同的响应式函数。
新版本采用函数高度复用的结构后，大量actions和mutaions里面的重复函数被提取出来。代码量减少了近50%。
quasar较新版本支持了composition-api和typescript编写项目，项目无需做独立的配置就能使用vue3新特性和typescript。这也说明quasar的社区支持是非常快和非常好的。
三、项目改造前后，页面编写风格对比
首先是template风格的页面对比：
改造前：
改造前，项目使用vuex模块分割和动态注册加上quasar提供的prefetch功能，页面在prefetch时候注册vuex，在页面beforeDestory钩子时候移除vuex注册，并清空states数据
改造后：
改造后，项目从单独的ts文件引入响应式和非响应式数据，并从另一个ts文件引入页面所需函数，并在setup中将数据传进函数进行调用。数据和函数均通过setup函数return给页面使用。
接着是render风格的页面对比：
改造前：
改造前直接使用options-api的render属性就行。
改造后
改造后，使用SetupFunction来返回VNode。
四、typescript编写注意事项
1、改用typescript编写项目，能够降低项目bug发生率，但是需注意把函数用到的变量结构提前定义成interface。这样，无论是在函数传参还是响应式数据更改时候，都能很规范的使用变量。
2、虽然typescript的泛型和类型推导功能，能够临时转换数据类型，但是这样会造成代码书写凌乱，不易读，也会增加bug产生几率。
3、提前定义好变量interface也更利于编写TSX风格的页面，TSX页面减少了标签代码的书写，增加了函数书写方式，页面大段的ts函数，若没有提前定义好interface，函数的编写将会非常耗时耗力。
4、js数组的filter方法换成ts编写要注意定义一个filter专用的interface类型接口，详情可查看ts官方github.
interface Filter{
label: {
indexOf(x: string, fromIndex?: number): number;
includes(x: string): boolean;
};
}
5、TSX编写或者直接使用render函数渲染时，render函数需要用到vue里面的VNodeData, VNodeChildren等数据类型。
typescript反面案例：
各种泛型，类型推导，强转类型。若非通用工具函数或者是框架类函数编写，强烈不推荐这种写法。
typescript正面案例：
提前定义好interface，多处引用interface，interface改一次，多处生效。
五、composition-api编写注意事项
1、vue页面script标签处注意加lang=‘ts’
2、export default 一定要调用最好defineComponent接口，defineComponent告诉vue渲染走composition-api接口，也能提供更好的typescript支持。
3、页面数据和函数入口都从setup属性开始，通过setup来return给页面，父组件props作为setup参数
4、vue3从Object.definePropety全面改成proxy模式，页面属性和全局变量不会暴露到this里了，部分属性需要从setup的第二个参数context里面取得。订阅全局数据和属性时候尽量轻量化订阅，尽量不用context大对象，用{ root, emit }来订阅context里面的数据和属性。
5、非父子组件的跨组件获取响应式数据不能走this了，有两个方法可以实现，1、响应式数据定义在单独的ts文件里，import到页面上来，跨组件获取数据可以照样import后获取。2、使用provide和inject。
6、获取dom的ref方法更新了，1、页面上定义ref='xxx'，2、setup属性里定义const xxx = ref(null)并且return xxx，3、页面dom渲染完成之后，setup里面通过xxx.value获取dom。
7、组件生命周期钩子变更，lifecycle hooks
六、添加pwa特性
pwa对网站总体有10项非常好的优化。但需要网站支持https，http2。
测试环境部署的话，我从阿里云买了9块钱的域名，申请了面费的https证书。http2是通过nginx配置来进行的支持。
quasar的项目只需要通过quasar脚手架，quasar mode add pwa,就能直接添加pwa支持，通过quasar build -m pwa，就能将spa的网页打包成pwa模式的网页。
个性化pwa配置也能修改quasar提供的配置
七、改用ssr服务端渲染，并保持pwa特性
服务端渲染需要注意生命周期、有状态单例、客户端水化等问题。编写页面时尽量避开使用ssr不支持的特性。
这里用quasar在配置文件里写好ssr配置pwa:true就能开启ssr服务端渲染叠加pwa模式。
打包后，我选用PM2工具就行前端的部署，并指定pm2集群模式，使用宿主机max cpu(pm2 start xxx.js -i max)。
整体链路是，https,http2请求通过nginx转发给本机pm2的运行端口。这样PM2无需部署https，http2，ssl证书。
八、打包对比
改造前：
改造前由于项目历史问题，没有使用ssr，只用了pwa模式
改造后：
可见，由于砍掉vuex，并高度复用了函数。代码打包后文件大小降低了近50%
九、网站性能
经过一番大型改造，网站性能全开。使用简单的测试工具，chrome自带lighthouse打分。各项指标基本满分。
pwa模式也完美生效。
最后总结，目前composition-api是作为vue2.6+的补充属性来使用的。未来vue3上面做的大量的性能优化首选都是通过composition-api来提供。vuex作为可选组件，在未来新vue项目的使用中，可根据具体项目需要选择是否使用，不一定为了composition-api而砍掉vuex。quasar虽然上手难度高，文档量大，前期学习成本高，但他对前端性能的优化是几乎做到了极致的。其他UI库虽然上手快，学习成本低，但是要做到quasar这么极致的性能优化，后期pwa和ssr优化工作所耗费的时间成本会更大。