uniapp+vue3+vite+pinia+ts 项目技术 + 框架详解

大家好，我又来了，作为一只菜鸡，文章更新的速度慢我觉得也可以理解~

上一篇文章我们讲了前端的命名规范，在这里我们先忽略一些，从命名规范--->实际项目中所需要的一些技术和手段，直接跳到项目框架详解这里，主要原因是因为，项目需求~~~

（中间的技术文我会悄悄更新，然后惊艳所有人！）

嘻嘻嘻，其实是最近有个项目是将手里vue2的一个app项目转为vue3技术栈，那么在升级的过程中，当然是要将配套的设施都整成最新的啦！~ 因此，在这次的搭建中，我就向大家讲解一下所使用的一些相对较新且成熟的一些框架和技术栈以及构建的项目的目录结构规范：

项目技术栈

---

开发框架：uniapp

官方地址：uni-app快速上手 | uni-app官网 (dcloud.net.cn)

详情：

uniapp是一款基于Vue.js的跨平台开发框架，由DCloud团队开发维护，可以帮助开发者快速地开发出具备良好体验的跨平台应用，目前支持vue2语法和vue3语法，最大的优势是可以让一套代码同时运行到多个平台（iOS、Android、Web（响应式）、以及各种小程序、快应用等），同时内置了很多API，有内部支持的路由跳转，网络请求，获取定位等指令，在开发一些轻量级的小程序或者是APP时，甚至无需安装额外的包就能实现一整套代码。

优点：

• 高效开发：Uniapp可以快速创建多端应用，并且可以编译到多个平台
  • （支持 IOS 和 Android 模拟器、微信开发者工具、内置/外置浏览器、真机运行等等）
• 性能优秀：Uniapp在渲染性能和内存管理上做了大量优化，保证了应用的流畅性和稳定性
• 扩展功能灵活：uniapp拥有一个自己的插件市场，并且支持开发者自由扩展和个性化定制
  • 插件市场地址：DCloud 插件市场
• 统一的API：UniApp 提供了统一的 API 接口，可以在不同平台上调用相同的接口，简化代码
• 独立的打包运行体系：这个是我个人的看法，Uniapp在一些应用发布或者上线的时候有较为严格和规范的流程，减少了很多隐形Bug和后期维护成本。

缺点：

• 风评很差：为什么把这个摆第一条！哈哈哈！ uniapp有很多不好用的地方必须吐槽一下！！！
  • 以下是网友看法：uniapp每次更新就像在拆炸弹！官方bug达到新高度，官方文档的坑也很多，不区分测试版和正式版，只知道更新新功能不知道维护旧版本，uniapp项目必须用Hbuilder编译器，然而编译器一堆坑~经常闪退，运行到微信开发者工具经常断联系，需要重新编译等等等等~~~
• 平台差异：尽管官方鼓吹，但是不同平台的差异还是存在，并且条件编译有些时候并不是很好用
• 编译依赖：这个就是一个坑，uniapp项目的编译必须依赖uniapp官方的编译器，隐形Bug容易出现
• 技术限制：uniapp的使用需要学习vue.js的基本概念和语法，对于一些 Reacter不友好
• 插件质量差：由于uniapp官方支持的UI库或者组件库较少，因此插件市场有很多杂七杂八的插件，但是很多插件都是个人发布的，经常会有一些莫名其妙的bug

不过，如果一些项目需要运行到多个平台，uniapp还是不二之选，在使用时尽量多去阅读官方文档，并且推荐使用uniapp自带的uni ui组件库，可以减少很多不必要的麻烦，并且减少代码体积，方便打包编译。

---

JS框架：Vue3

官方地址：Vue.js - 渐进式 JavaScript 框架 | Vue.js (vuejs.org)

详情：

什么是 Vue，不用我多说了吧，一款 js 框架，最初是由尤雨溪个人创建的独立项目，目前由来自世界各地的全职成员和志愿者组成的团队积极活跃地维护着，Vue 提供了声明式、组件化的编程模型，使用 MVVM 数据双向绑定模式，提供组件的全生命周期函数，方便开发者在不同时期进行一些操作等等...

优点：

• 更快的渲染速度：vue3 使用 proxy 代理和优化虚拟 DOM 算法等方式提高渲染性能
• 更小的体积：vue3 相比于 vue2 体积更小，打包后文件加载速度更快
• 更好的类型支持：vue3 对 typescript 的支持更加友好
• 更好的组合式API：vue3 的组合式 API 使得组件的复用和维护更加方便
• 更好的Tree-sharking支持：方便优化打包后的代码

缺点

• 生态系统相比于 react 不够完善
• 缺少一些官方支持，因为 vue 的创作者是个人，并且由一些个人团队维护，更新起来较慢
• 不适合于大型项目，更适合中小型项目

迭代版本：

vue3 ---> vue3.1 ---> vue3.2 --->vue3.3 ---> vue3.4 （目前最稳定的版本是3.4）

新技术：

在 vue3 迭代更新的过程中也出现了很多新的技术，后期会出文章总结每一次迭代更新的技术，其中一些技术使用还是较为广泛的，换句话说，你没有用这些技术就等于你没有在用 vue3

---

构建工具：Vite

官方地址：Vite | 下一代的前端工具链 (vitejs.dev)

详情：

Vite是一款由原生 ES Module 驱动的 Web 开发构建工具，与 Vue CLI 类似，Vite 也是一个提供基本项目脚手架和开发服务器的构建工具，但是 Vite并不是基于webpack的，它有自己的开发服务器，采用Rollup进行构建，速度更快，与webpack相比较，Vite 是先启动服务，按需加载，webpack 则是先全部打包，再启动服务。

主要特性：（粘贴自文章：Vite介绍及实现原理<超详细、纯干货！> - 知乎 (zhihu.com)）

• Instant Server Start ------ 即时服务启动
• Lightning Fast HMR ------ 闪电般快速的热更新
• Rich Features ------ 丰富的功能
• Optimized Build ------ 经过优化的构建
• Universal Plugin Interface ------ 通用的Plugin接口
• Fully Typed APIs ------ 类型齐全的API

主流构建工具对比：

Browserify

• 预编译模块化方案（文件打包工具）
• Browserify基于流方式干净灵活
• 遵循commonJS规范打包JS
• 可引入插件打包CSS等其他资源（非原生能力）

Gulp

• 基于流的自动化构建工具（工程化）
• 配置复杂度高，偏向编程式，需要定义task处理构建
• 支持监听读写文件
• 可搭配Browserify等模块化工具来使用

Parcel

• 极速打包（工程化：极速0配置）
• 零配置，但造成了配置不灵活，内置常见场景的构建方案及其依赖，无需再次安装（babel等）
• 以html入口，自动检测和打包依赖
• 不支持SourceMap
• 无法Tree-shaking

Webpack

• 预编译模块化方案（工程化：大而全）
• 通过配置文件达到一站式配置
• loader进行资源转换，功能全面（css+js+icon+front）
• 插件丰富，灵活扩展
• 社群庞大
• 大型项目构建慢

Rollup

• 基于ES6打包（模块打包工具）
• Tree-shaking
• 打包文件小且干净，执行效率更高
• 更专注于JS打包

Snowpack

• 基于ESM运行时编译（工程化：ESM运行时）
• 无需递归循环依赖组装依赖树
• 默认输出单独的构建模块（未打包），可选择不同打包器（webpack、rollup等）

Vite

• 基于ESM运行时打包
• 借鉴了Snowpack
• 生产环境使用Rollup，集成度更高，相比Snowpack支持多页面、库模式、动态导入自动polyfill等

总之，Vite在 将来的使用将会越来越多，毕竟真香的技术，没有哪个码农会拒绝！

---

状态管理：pinia（大菠萝）

官方地址：Home | Pinia 中文文档 (web3doc.top)

详情：

什么是pinia？

答：状态管理工具！

什么是状态管理？

答：简而言之，就是我在组件 A 中改变了一个数据，我希望在不通过向后端发送请求和浏览器缓存的方式，来改变组件 B 中的数据。

有的小伙伴可能会疑惑，为什么不用父子组件传参的方式？如果是单纯的父子组件之间，通过简单的传参就可以改变一些数据，但是组件之间的嵌套往往较为复杂，甚至有些兄弟组件之间传参，要借用父组件来搭建桥梁，如果嵌套的组件深了，数据流就会变得极为麻烦。因此，状态管理应运而生！使用过vue2的小伙伴应该都熟悉vueX ，可以这么说，pinia就是vueX的新版本，并且适用于vue3，不过，pinia和vueX都可以在vue3中使用，但是尤大大推荐使用pinia来进行状态管理。

优点：

• Vue2和Vue3都支持，这让我们同时使用Vue2和Vue3的小伙伴都能很快上手。
• pinia中只有state、getter、action，抛弃了Vuex中的Mutation，Vuex中mutation一直都不太受小伙伴们的待见，pinia直接抛弃它了，这无疑减少了我们工作量。
• pinia中action支持同步和异步，Vuex不支持
• 良好的Typescript支持，毕竟我们Vue3都推荐使用TS来编写，这个时候使用pinia就非常合适了
• 无需再创建各个模块嵌套了，Vuex中如果数据过多，我们通常分模块来进行管理，稍显麻烦，而pinia中每个store都是独立的，互相不影响。
• 体积非常小，只有1KB左右。
• pinia支持插件来扩展自身功能。
• 支持服务端渲染。

缺点：

• pinia不支持时间旅行和编辑等调试功能，个人感觉实际使用中暂未发现不妥（没怎么使用）
• 缺少生态支持，pinia没有庞大的社区支持，有时候有问题的话只能自行摸索
• 使用时需要搭配一个数据持久化插件，为什么要持久化？
  • 在使用pinia的过程中，如果你在组件中修改了 store 中的数据并调用了刷新函数，Pinia 会将 store 中的数据重置为初始值，从而导致数据丢失的问题

什么时候用pinia？什么时候用vueX？

• Pinea是轻量级的，体积很小，适合于中小型应用，也适用于低复杂度的Vue.js项目
• Vuex 是重量级的，对项目的性能降低有很大影响，因此，构建大型项目的时候推荐使用vueX
• 在开发一些结合uniapp框架的小程序或APP项目时，推荐使用pinia

---

Typescript

官方地址：TypeScript: Handbook - Basic Types (typescriptlang.org)

中文文档手册：TypeScript 中文网 (nodejs.cn)

vue.js中有关ts的介绍：搭配 TypeScript 使用 Vue | Vue.js (vuejs.org)

详情：

什么是Typescript？

答：TypeScript 是拥有类型语法的 JavaScript（官方解释）

通俗点：高级JS！

具体点：TypeScript 是基于 JavaScript 创造的强类型编程语言，可以进行任意程度的扩展，TypeScript 适合构建大型应用，适合团队开发。从技术上来讲，TS就是具有静态类型的JS，并且TS可以被编译为纯JS。同时，TypeScript可以在任何可以使用JavaScript的地方使用：包括前端和后端。

插播一条补充： （借鉴原文：TypeScript是什么，为什么要使用它？ - 知乎 (zhihu.com)）

类型简介

什么是类型？类型是在我们运行程序之前通过在代码中描述我们计划如何使用数据来区分正确程序的方法。它们可以从简单的类型(如数字和字符串) 到为我们的问题域完美建模的复杂结构。

• 编程语言分为两类：静态类型或动态类型。

• 在使用静态类型的语言中，变量的类型在编译时必须是已知的。如果我们声明一个变量，编译器应该知道(或可推断) 该变量是数字、字符串或布尔值。

• 在动态类型的语言中，不一定是这样，只有在运行程序时才知道变量的类型。

所以，TypeScript可以支持静态类型，而JavaScript不支持。

很多对JS还学的不透彻的小伙伴（本人），去学 TS 会有很多疑惑，同样的语法，为什么要这么写？不慌，我们来看看TS有哪些优势，不过最终大都逃不过真香定律，相信不久后的我也会（真香）~

优点：

• 提供可选的强静态类型语言：可以对变量设置类型，为了兼容JS，也可以设置为 any 类型（可以赋值任何类型）方便转换！
• 提前发现BUG：TS是编译后才能使用，所以类型错误会在编译过程中被发现，改不对别想通过编译！
• 代码可预测：TS声明的变量一旦指定类型，那么它的类型就再也不能修改，在一些函数或者方法中的输入输出的值将会是可控的，防止变量变来变去！
• 丰富的IDE支持：目前绝大多数的IDE（集成开发环境）中已经支持TS的智能提示，自动补全，代码导航...
• 方便重构：代码重构时，如果函数的参数修改了，调用时报错，TS会提示你，前提是不要到处用any！
• 面向对象写法：TypeScript 支持接口、抽象类、枚举等面向对象语言的特性

缺点：

• 不是真正的静态类型，因为有any的存在
• 有一定的学习成本，不在项目中实际使用，看文档学习很难以理解（我就是）
• 代码量变多，很多小伙伴的疑惑，明明JS写起来更省事，为什么要这么复杂的写，一方面是规范如此，另一方面也是为了更好的维护
• 需要编译，浏览器和nodeJS不支持TS，所以实际开发过程中多了编译操作，对普通开发者来说没什么影响

总之：TS利大于弊，并且是前端开发的主流技术，有必要掌握！

---

项目框架目录详解

其实在做项目时，最先应该了解的是项目的结构，也就是整个项目的文件目录及其含义，使用不同的技术栈和框架时目录结构并不是相同的，但大多数大同小异，有些目录的命名规范也是大家墨守成规的（没有明确要求，但大家都默认这么遵守），所以在实际开发过程中，个人和团队之间都应该遵守这样的规范

vue3 项目框架目录

一个vue3项目代码结构图示：

src文件夹展开的结构如下：

其中，很多文件夹不是必须的，视需求而定，下面我详细讲一下使用脚手架建立的vue3项目给出的初始目录结构详解：

|-node_modules       -- 所有的项目依赖包都放在这个目录下
|-public             -- 公共文件夹，存放一些不经过构建工具处理的文件，例如HTML文件、图标等
---|favicon.ico      -- 网站的显示图标
---|index.html       -- 入口的html文件，可以设置一些meta头部信息，挂载vue节点
|-src                -- 源文件目录，编写的代码基本都在这个目录下（和uniapp项目结构最大的区别）
---|assets           -- 放置静态文件的目录，项目所需要的图片等
---|components       -- 公共组件文件夹，自定义的组件都会放到这
---|router           -- 路由管理文件夹：vue-router路由的配置文件
---|store            -- 状态管理文件夹：存放vuex或者pinia的文件
---|views            -- 存放视图文件，也就是我们写的页面会放到这里
---|App.vue          -- 根组件，这个在Vue2中也有
---|main.ts          -- 入口文件，因为采用了TypeScript所以是ts结尾
|-.eslintrc.js       -- Eslint的配置文件，用到了就配置
|-.gitignore         -- 用来配置哪些文件不归git管理
|-package.json       -- 查看脚本命令配置和一些依赖以及包的版本号
|-README.md          -- 项目的说明文件，使用markdown语法进行编写，一般会放运行命令/打包命令
|-vue.config.json    -- 请求代理, webpack 配置, 打包输出等都会在这里配置
|-vite.config.ts     -- 如果是用vite构建的则会显示这个文件，没有上面的文件
|-yarn.lock          -- 使用yarn后自动生成的文件，安装yarn包时的重要信息存储到yarn.lock文件中

细心的小伙伴会发现官网给出的代码结构和实际项目中的有些出入，这是因为有些目录是根据实际使用来自行创建的，在src文件夹中常用的一些新增文件夹及其含义如下：

...
|-dist               -- 打包后生成的文件夹，存放打包后的项目文件（web端）
...                  
|-src                -- 源文件目录
---|api              -- 存放网络请求的文件夹，在里面还会根据需要区分请求的文件      --- 新增
---|assets           -- 放置静态文件的目录，项目所需要的图片等
---|components       -- 公共组件文件夹，自定义的组件都会放到这
---|hooks            -- 存放一些公共的JS的文件，自定义的方法或者函数放这里          --- 新增
---|router           -- 路由管理文件夹：vue-router路由的配置文件
---|store            -- 状态管理文件夹：存放vuex或者pinia的文件
---|styles           -- 存放一些公共的样式，或者是自定义的主题样式文件              --- 新增
---|views            -- 存放视图文件，也就是我们写的页面会放到这里，PC端也可以叫pages
---|utils            -- 一些额外使用的工具配置文件，例如：echarts的配置文件等       --- 新增
---|App.vue          -- 根组件，这个在Vue2中也有
---|main.ts          -- 入口文件，因为采用了TypeScript所以是ts结尾
...                  
略
...
|-.env.XXX           -- 配置不同的生产环境的地方
|-.package-lock.json -- npm install时生成的一份文件，记录在当前环境下实际安装的包来源和版本号
...

实际开发过程中，项目的目录结构会根据项目的需要由一些细微的差别，甚至有些文件的命名并不会像我所说的这样，大家不用担心，也不用纠结，根据公司或者团队的习惯来就好，如果不适应所做项目的目录结构，我的建议是：重写一份，按照自己的习惯来，并且让大家都按照你的习惯来（会被打哈哈哈哈哈哈哈哈哈哈哈）~

---

uniapp 项目框架目录详解

虽然你使用uniapp框架时使用的也是vue3语法，但毕竟你编译的时候用的是uniapp的编译器，所以uniapp也有一套自己的项目结构，和vue3（web端）的项目结构还是有一些出入的，因此在编写小程序或者APP项目时，还是需要依照uniapp的规范来~

莫要慌张，uniapp官网有给出一份目录结构详解（拿捏）：

不高清是吧，我也觉得， 但是截图就是酱紫，可以移步官网查看：工程简介 | uni-app官网 (dcloud.net.cn)

官网也给出了项目结构中一些需要注意的tips：

• static目录 使用时注意：

  • 编译到任意平台时，static 目录下除不满足条件编译的文件，会直接复制到最终的打包目录，不会打包编译。非 static 目录下的文件（vue、js、css 等）只有被引用时，才会被打包编译。
  • css、less/scss 等资源不要放在 static 目录下，建议这些公用的资源放在自建的 common 目录下。

• HbuilderX 1.9.0+ 支持在根目录创建 ext.json、sitemap.json 等小程序需要的文件。

上面的讲解是否有些迷惑，那么我们给出一个通俗版：

- pages					页面存放目录
- static				静态资源目录（如图片、视频等，静态文件只能存放到这里）
- App.vue				应用入口文件（跟小程序 app.js 类似，如：APP全局样式、监听声明周期）
- main.js				应用入口文件（如：Vue 初始化、定义全局组件 ...）
- manifest.json			        项目配置文件（如：应用名称、appid、logo、版本、启动页 ...)
- pages.json			        页面配置文件（如：页面路由、导航条、选项卡 ...）
- uni.scss				全局样式（如：按钮颜色、样式风格 ...）
- unpackage				编译后的文件存放目录

- 注意：下面需要自建的，根据项目开发情况创建即可。

- api					请求封装存放目录（自建）
- common				公共文件存放（自建）
- components			        自定义组件存放（自建）- uniapp
- wxcomponents			        小程序组件存放（自建）- wx
- store					vuex/pinia 状态管理（自建）
- utils   				公共工具目录（自建）
- hybrid				存放本地网页目录（自建）
- platforms				存放各平台专用页面目录（自建）
- vue.config.ts			        vue 配置管理（自建）
- vite.config.ts                        vite 配置管理（自建）

给大家看一个实际项目中（Vue2转Vue3那个）的uniapp项目目录结构：

和官方的要求基本上是对照的，这里也有一些小tips告诉大家：

• components文件夹中，自定义组件时，不建议嵌套，并且为每一个组件定义一个同名文件夹，这样可以不用引入就可以在全局中使用组件，如果不这样的话，按照vue3的语法，自定义组件需要在文件中引入，并且自定义组件必须以大写字母开头（为什么这样我也不太理解，大家可以百度一下） 例如：

• pages页面中，建议是为每一个单独的页面也创建一个同名文件夹，并且为每一个在当前页面单独使用的组件定义一个components文件夹用来存放自定义组件，同时，在小程序或者APP项目中，为了方便管理，pages下面的第一层文件应当按照底部的菜单栏或者是功能划分文件夹，并为一些不属于这些模块的页面单独建立一个文件夹，名称尽量接近文件本身的含义

举个栗子：

一些错误页、需要用webview承载的H5页面，或者是登录页等等，可以放到other文件夹下，这样页面和代码结构就会一目了然~~~

好了，今天的文章总结到这里了，这些总结类的，是想让一些小伙伴在实际做项目的时候，先了解好基础，具体哪部分知识点薄弱，可以去针对性的学习，还有就是，在实际的项目中就会对一些技术慢慢熟练，所以大家不要慌张~