分类 前端 下的文章

store-persistedstate-killer

EN / 中文

杀手级别的持久化状态管理库


  • 可以为多个库提供持久化服务 (vuex, pinia)
  • 支持 TypeScript
  • 支持 预定义存储驱动 (localstorage, sessionstorage) 以及自定义驱动
  • 支持相对安全的存储环境(非明文)
  • ‍灵活的配置且没有副作用
  • 对开发友好的状态变更 Log
  • 持久化加强功能 (重命名...)

安装

npm i store-persistedstate-killer

快速使用

// main.ts
// pinia平台
import { plugins as killer, config } from 'store-persistedstate-killer'

createApp(App)
  .use(
    createPinia().use((context) => {
      killer.pinia.init(context)
      killer.pinia.use(context)
    })
  )
  .mount('#app')

Demo

Edit objective-sun-1wmt7

目标

  1. 用状态管理接管你的 storage,从此无需担心类型,像操作 store 一样操作 storage 即可
  2. 前端存储不再明文

killer 做的事情

设计

每一个平台的插件你可以单独引入它们,比如你是 pinia 平台,那你仅仅这样引入就可以了

createApp(App)
  .use(
    createPinia().use((context) => {
      killer.pinia.init(context)
      killer.pinia.use(context)
    })
  )
  .mount('#app')

killer 中每一个插件都包含2个部分, 一个就是 init,一个是 use

init

在应用初始化时,把我们 storage 内容同步到 store 中; 如若发现 store 有,但是 storage 没有的 state,也会执行一次同步。这个过程是双向的。在文档上方就有一个 killer的概要图,我们如果站在状态管理的视角下,可以理解 storage 为远端,双方的交流就可以当作pushpull

use

use 是 killer 的核心功能,它可以监听 state 的变更以及 patch 操作,它可以实时地把 state 同步给 storage


如你所见,如果你的业务中,仅仅需要监听 state 然后同步到 storage 这个需求,你也可以仅使用 use 这个插件

如果想看到更多有关平台插件的文档,你可以移步具体的文档中(就在下方)

支持的平台/库

PlatformLibDoc
pinia2
vuex4/5

核心

killer 为各个平台的插件提供了多个核心,使它们能够正常运转,每一个核心主要负责一个业务,比如说配置,加密,存储

配置

killer 本身自带一个开箱即用的配置,你如果有特殊的需要,可以去自定义它们。在此之前你需要了解各个插件的工作原理,我们以 pinia 举例子。pinia 由一个一个 store 组成,store 由 state,getters,action 组成,所以 killer 仅仅是在useStore()之后才运行的插件,killer 接管了 store 的 state,使之能够持久化到本地存储中;那么在持久化的过程中,我们可能需要做一些重命名, 加密数据等工作...

配置名含义类型默认建议
exclude排除指定的仓库名string[ ][ ]
include包含指定的仓库名string[ ][ ]
prefix缓存的key前缀stringpersistedstate-killer-建议传入有效的字符串
iv加密需要用的iv变量string''可以为空
isDev是否是开发环境booleanprocess.env.NODE_ENV === 'development'如果为false将自动加密
storageDriver插件预定义的存储驱动defineStorageDriverdefineStorageDriver('localStorage')支持传入localStorage和sessionStorage
store对仓库进行详细配置Partial<Record<K, StoreConfig>>没有默认配置
defineStorage自定义存储驱动setItem, getItem, removeItem, iteration没有默认配置如果预定义存储驱动defineStorageDriver没有满足你的需求,可以使用这个方法定义新的驱动

你的工程中的自定义配置可能就像这样:

import { plugins as killer, config } from 'store-persistedstate-killer'

createApp(App)
  .use(Router)
  .use(
    createPinia().use((context) => {
      config.defineConfig<'main'>({
        exclude: ['zhangsan'],
        include: ['main', 'test'],
        isDev: true,
        storageKey: 'seho',
        store: {
          main: {
            state: {
              hello: {
                rename: 'wuyu',
              }
            }
          }
        }
      })
      killer.pinia.init(context)
      killer.pinia.use(context)
    })
  )
  .mount('#app')

你可以看到, killer 提倡使用 ts 来构建插件,我们可以给 defineConfig 传入一个联合类型,声明需要对哪几个 store 进行操作,此时如果你在编写 include 和 store 配置时,将会有非常棒的类型提示。

ApiDescType
defineConfig注入配置doc

加密

前端的加密难道没有必要么?确实有人这么说,但是当我们把状态管理的数据明文暴露到 localstorage 中确实不是很好,尽管我们现在都这么做 。我们需要一款易用的加密,不仅可以给 killer 中内部使用,而且还可以暴露给用户,让用户可以加密 api,交换特殊信息?killer 内部使用了crypto-js,默认使用了浏览器ua -> base64, 同时你也可以根
据业务需要指定 key 和 iv。

import { crypto } from 'store-persistedstate-killer'

const _crypto = new crypto()
const message = 'hello, messagehello, messagehello, messagehello, messagehello, messagehello, messagehello, message'
const encryptData = _crypto.encrypt(message)
if (encryptData) {
  const decrypt = _crypto.decrypt(encryptData)
  console.log('解密结果', decrypt)
} else {
  throw Error('加密错误')
}

我们可以给构造函数传递一个 ctx

const _crypto = new crypto({
  iv: 'asdasdasdasdasdasdasdasd',
  key: 'sssaasdasdasdas234234s'
})

查看加密模块的类型声明

ApiDescType
encrypt加密` (data: string) => string \null`
decrypt解密` (data: string) => string \null`

原文链接:因卓诶-简单聊聊前端渲染模式以及Nuxt3.js

前言

最近的工作有涉及到ssr,所以这篇文章算是一个总结,并且对还在beta阶段的nuxt3做一个浅析。前段时间有一个蛮火的视频,关于rollup作者rich的一段演讲,在演讲里面rich梳理了ssr和csr,并且讲述了痛点,和提出新的概念“transition app”,如果你有兴趣可以看看这个视频

在文章开始前,我来简单介绍一下"spa", "mpa", "ssr", "csr"......这些个名词的意义。如果你是做web前端开发的,这几个词可能伴随着你的工作生涯很久很久了,相关文章互联网上多如牛毛,如果你对这些概念比较模糊甚至压根不知道,那么别关闭网页,我希望这篇文章能够拯救你。

SPA与MPA

MPA称之为“多页应用”, 那么什么是多页应用呢?字面意思其实就是有多个页面的应用就是多页应用。从技术手段上来讲,你可以这么粗略地理解。SPA,MPA不同点太多了,而且各有利弊。

MPA应用你需要单独维护多个html页面,而且我们每加载/切换一次页面,都需要加载一整个页面。但是它对于seo特别友好,因为我们可以给每一个html页面设置不同的meta等信息,从而达到更好的收录效果;所以MPA多出现在大型的电商/新闻网站等。

不同于MPA,SPA可以使得我们通过ajax或者其他技术动态的更改某一个区域的内容而不需要重新加载页面,包括切换页面也不会重新加载整个html,它对状态的留存做的很好,而且在移动端表现特别优异(因为在以前流量是很珍贵的,可以以最小的损失切换页面,无论是用户体验还是成本相较于MPA都是极大的改善)

SSR

在我们web较早的时候,开发者喜欢使用jsp或者其他模板渲染引擎来构造一个应用。我们一般称之为SSR(服务端渲染) 它的大致架构是如下这个样子

untitled.png

用户发起一个请求抵达后端服务器后:

  1. 后端会将用户所需要的内容通过数据层进行查询
  2. 处理业务
  3. 通过模板来拼接页面
  4. 返回一个html字符串给客户端
  5. 前端渲染然后加载js脚本完成剩余交互

你可能也发现了,在SSR服务端渲染中,前端负责的东西太过单薄,说得好听叫交互,难听点就是“点击事件工程师”。所以老一辈的后端基本人人都会前端,js的水平高的一抓一大把。随着使用SSR渲染页面的应用越来越多,弊端也出现了:

  1. 后端做了太多事情了,再牛逼的人也吃不消
  2. 前后端耦合,维护难度升级
  3. 内容更新/跳转,都需要重新加载一次页面
  4. 服务端渲染成本很高
  5. ...

CSR

CSR(客户端渲染)大致是以下的架构:

csr.png

CSR架构更贴近我们的现代前端开发,我们一般使用VUE, REACT这一类的前端视图框架时,都是默认CSR体系的。大致的流程是下面这样子的:

  1. 浏览器向前端服务器请求html和js,html页面是空html,并且同时执行js
  2. js渲染页面
  3. 通过后端暴露的api进行交互

SSR和CSR的区别

可以发现,使用CSR进行开发,会有几个明显的缺点

SEO

因为从前端服务器获取的html最开始是空html,这非常不利于seo,很多搜索引擎的老版本蜘蛛会直接爬页面,不会等待js加载完,所以会直接爬出来一个空页面。尽管现在的百度,谷歌等搜索引擎的爬虫能力很强,能够部分支持CSR SPA页面,SEO效果虽然可以其他方式弥补 (比如加入meta标签等等); 但是我们使用SSR完全不用担心,因为获得的html页面是一个完整的,可以直接渲染的。

用户体验(白屏)

关于白屏,由于CSR从HTML构建完成到JS渲染页面完成(但还没呈现页面)这一段过程中,是处于一个白屏的时间,用户体验很不好,反之使用SSR获得HTML之后只需要直接构建DOM就可以了。

同样的,我们使用SSR还有不一样的缺点:

  1. 成本问题(相比CSR多了构建HTML以及获取数据,需要更多的服务器负载均衡)
  2. 部署问题(与CSR部署环境不同,不是仅仅需要一个静态文件托管服务器那么简单了)
  3. 代码难度问题
  4. ...

使用Vite快速构建一个SSR(实践SSR)

Vite SSR虽然现在是一个实验性质,不能用于生产环境。但是我们可以使用Vite做一个ssr的demo,帮助我们理解SSR的构建,理解之后我们再来引入"Nuxt", "同构"等概念。Vite里面为SSR提供了很多支持,所以我们要开发一个demo,会非常非常简单,你也可以参考这篇官网文档

我们首先需要更改index.html的内容

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" href="/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite App</title>
  </head>
  <body>
    <div id="app"><!--ssr-outlet--></div>
    <script type="module" src="/src/entry-client"></script>
  </body>
</html>

可以看到我们在app的div里写了一段注释,到时候我们渲染完之后的html将会replace这个注释。

然后需要在根目录新建一个server.mjs,作为我们的服务入口,用express作为一个例子:

// server.mjs
import { readFileSync } from 'fs'
import { resolve } from 'path'
import express from 'express'
import { createServer as createViteServer } from 'vite'

const createServer = async () => {
  const app = express()
  const vite = await createViteServer({
    server: { middlewareMode: 'ssr' }
  })
  // 使用vite这个中间件
  app.use(vite.middlewares)
  app.use('*', async (req, res) => {
    try {
      // 服务 index.html - 下面我们来处理这个问题
      const url = req.originalUrl
      // 读取根目录的模板
      let template = readFileSync(resolve('index.html'), 'utf-8')
      // 转换index.html 使其hmr有效
      template = await vite.transformIndexHtml(url, template)
      // 加载entry-server这个文件中的render方法
      const { render } = await vite.ssrLoadModule('./src/entry-server.js')
      // 根据url进行渲染
      const appHtml = await render(url)
      // 替换注释为准备好的html
      const html = template.replace(`<!--ssr-outlet-->`, appHtml)
      res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
    } catch (error) {
      vite.ssrFixStacktrace(e)
      console.error(e)
      res.status(500).end(e.message)
    }
  })

  app.listen(3000)
}

createServer()

我们的main.js也需要更改

// src/main.js

import App from './App.vue'
import Router from './router'
import { createSSRApp } from 'vue'

export function createApp() {
  const app = createSSRApp(App)
  app.use(Router)
  return { app, router: Router }
}

我们在main.js中,从vue导出createSSRApp函数,并且使用router,并且返回一个对象,这个对象之后将会被entry-server引用。

那么router也和我们传统的csr应用不太一样,我们根据env判断,传入了不同的路由类型:

// src/router/router.js

import { createRouter, createWebHistory, createMemoryHistory } from 'vue-router'

const Router = createRouter({
  history: import.meta.env.SSR ? createMemoryHistory() : createWebHistory(),
  routes: [
    {
      name: 'index',
      path: '/index',
      component: () => import('../pages/index.vue')
    }
  ]
})

export default Router

然后我们需要在src中新建 entry-client.js(会被index.html引入) 以及 entry-server.js

// src/entry-client.js

import { createApp } from './main'

const { app, router } = createApp()

router.isReady().then(() => {
  app.mount('#app')
})
// src/entry-server.js

import { createApp } from './main'
import { renderToString } from 'vue/server-renderer'

export const render = async (url) => {
  try {
    const { app, router } = createApp()
    // url跳转一下路径
    router.push(url)
    // 路由准备好
    await router.isReady()
    const ctx = {}
    // 返回一个html
    const html = await renderToString(app, ctx)
    return html
  } catch (error) {
    // console.log(error)
  }
}

到此为止我们可以在本地启动一个服务器,并且可以将我们的页面以ssr的形式渲染到浏览器中了,由于我们的demo代码都是esm,所以我们使用node执行,必须要写成mjs的后缀。

node server.mjs

启动服务器之后,访问/index这个路由,你就能看到我们的页面了

如果你的node版本不支持mjs,请先升级...

ssr示例项目:

  1. 本篇文章的demo
  2. 官方的demo

喝水,脱水,注水(SSR)

读到这里,你或许已经对ssr的流程有一个粗略的了解了;那么这一part的三个例子会加深你对ssr的理解,就是ssr常常说的喝水,脱水,注水

我们ssr在服务端构造页面时,数据是从数据源流下,使得我们页面数据得到填充,这个过程就叫做喝水(render & beforeRender)
喝水的过程就是在服务端渲染页面做的事情,就好比下面这个图:

1.png

饱满的水气球代表了一个健壮的网页

我们实现ssr需要直出html,所以需要把结构以及数据进行脱水 (如图)

fpic6008.jpeg

然后到了客户端,我们需要ssr应用重新焕活,就要让原本脱水了的state,prop等等数据恢复到原来的生机,并且重新render组件,这个过程就叫做注水

SSG

SSG这种渲染模式采取了CSR和SSR的共同优点,它不需要开发者介入服务器操作,开发者只需要准备cdn或者其他静态网页托管服务器,prerender出静态资源这一步将在构建时就已经做了,呈现在用户眼前的虽然不是实时变更的,但是也保留了CSR和SSR的精髓,一定程度上有了平衡。但是因为prerender的缘故,它和SSR的大致工作方式会相似一点。

也是有缺点的

  1. 随着业务的复杂,需要生成的页面可能不单单只有1,2个,所以这对于构建的要求很高
  2. 时效性问题,用户可能看到的页面是上一次生成的,所以这一部分仍需要其他模式来补充...

同构SSR和CSR(共享data)

同构说白了,就是将我们的前端代码,既能在客户端运行,也能在服务端运行,而且还能保持上下文的状态,我们在上面的改造例子已经实现了同一份代码在2个端的运行,但是并没有实现状态的同步,比如我们在nuxt中,使用asyncData这类钩子一样,能在服务端运行而且返回的data可以和客户端共享。

// 在nuxt2中我们可以这样
async asyncData({ store, $axios, $oss }) {
    return {
        hello: "world"
    }
}
<div>{{hello}}</div>

我们现在需要改造我们的demo:

// index.vue
// 新增一个option
asyncData() {
   return {
     hello: 'message'
   }
 }

其次在server端将asyncData返回的对象和其他页面html一起进行脱水:

// entry-
import { createApp } from './main'
import { renderToString } from 'vue/server-renderer'

export const render = async (url) => {
  try {
    const { app, router } = createApp()
    router.push(url)
    await router.isReady()
    let data = {}
    // 命中路由组件,且执行asyncData这个函数
    if (router.currentRoute.value.matched[0].components.default.asyncData) {
      const asyncFunc = router.currentRoute.value.matched[0].components.default.asyncData
      data = asyncFunc.call()
    }
    const html = await renderToString(app)
    return { html, data }
  } catch (error) {
    // console.log(error)
  }
}

// 我们的server.mjs也需要变更一下

// server.mjs

app.use('*', async (req, res) => {
    try {
      // 服务 index.html - 下面我们来处理这个问题
      const url = req.originalUrl
      let template = readFileSync(resolve('index.html'), 'utf-8')
      template = await vite.transformIndexHtml(url, template)
      const { render } = await vite.ssrLoadModule('./src/entry-server.js')
      const { html: appHtml, data } = await render(url)
      // 拼接标签,把data序列化插入到文档中
      const html = template.replace(`<!--ssr-outlet-->`, `${appHtml}<script>window.__data__=${JSON.stringify(data)}</script>`)
      res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
    } catch (error) {
      vite.ssrFixStacktrace(e)
      console.error(e)
      res.status(500).end(e.message)
    }
  })

可以看到我们将data序列化到了window对象中了,接下来我们需要在client端注水的时候,把新data进行替换

// entry-client.js

router.isReady().then(() => {
  const component = router.currentRoute.value.matched[0].components.default
  let _data = {}
  // 判断是否是函数
  if (typeof component.data === 'function') {
    _data = component.data.call()
  }
  // 判断是否有脱水的data
  if (window.__data__) {
    _data = {
      ..._data,
      ...window.__data__
    }
  }
  component.data = () => _data
  app.mount('#app')
})

这个时候我们已经成功的看到index.vue中能够正确的在template中打印hello这个字段了

到这里,你就可以举一反三,使用vuex也可以进行同步数据,都是把data序列化到window中保存,然后在client挂载前重新commit到store里面就可以了。

Nuxt3

是时候引入nuxt了,我们如果使用nuxt将会更容易的完成ssr需求,这一部分不会教大家怎么写nuxt,毕竟都是框架,都很简单。我会和大家梳理一下nuxt2和nuxt3的变化,如果你用过nuxt2,那么这一部分内容你可能会非常感兴趣。写这篇文章的时候,nuxt3并没有release,所以到时候release后会考虑再出一篇总结。

值得关注的更新内容

  1. 更好的性能
  2. esm的支持
  3. vue3更好的集成,说明我们可以使用composition api了
  4. vite开发服务器加持
  5. webpack5 支持(尽管我不用)

Nitro Engine

简单翻阅了一下文档,和大家分享一下,在nuxt3中的新服务端引擎 Nitro Engine, nuxt2中服务端核心使用的是connect.js,而nuxt3使用的是nuxt团队自研的h3框架,特点就是具有很强的可移植性,而且非常轻量级,并且还支持connect编写的中间件。也就是说nuxt3基于h3编写的server端,可以无缝地移植到支持js运行环境的地方,比如说woker,serverless...

我们先试试,开发一个在nuxt3中使用的api

// server/api/hello.ts
export default (req, res) => {
  return 'Hello World'
}

同样,支持异步,也支持nodejs风格的调用

export default async (req, res) => {
  res.statusCode = 200
  res.end('hello world')
}

nuxt3也支持在同一个server文件夹中编写middleware,而且是自动导入的。nuxt3这次的更新,属于是把文件系统玩出花了,不光plugins不需要重复声明了(nuxt2要在config重复声明),而且components,composables(nuxt3新增的文件夹,可以存放公共hook)... 都可以支持自动导入。

试想一下,如今写nuxt3应用,搭配vue3 composition api,将会使开发体验上升好几个台阶。

文末,我们可以试试打包一个nuxt应用到cloudflare 作为woker运行是什么效果?我们在build之后会发现output文件夹很简洁(不像nuxt2迁移部署都很令人头疼)

我们不仅可以在最后的demo中看到页面,也可以访问 api/hello 这个路由查看刚刚我们在nuxt中定义的api

点击访问
部署到cloudflare-文档
demo地址

结语

又是水文一篇,希望以后可以出一些高质量的总结文章,希望这篇文章所讲述的前端常见的渲染模式,你能够知道,并且知道原理,这也就是本文最终的目标。框架会不会都没关系,我们要洞悉一切技术背后的真相,再去研究框架不是手到擒来么?

前言

我们在开发中可能会经常遇到以下几个事情:

  1. api接口文档描述不清
  2. 没有mock流程
  3. 如果使用ts开发,需要手动的描述类型,而且在前端中较难把api类型复用

社区中有大量的api文档工具,支持mock,单测的数不胜数。但是有生态,而且有开放api的开源文档工具其实寥寥无几。yapi是开源的国产文档管理工具,我们可以用yapi的开放api去做一系列拓展,在市面上就有许多浏览器插件/vscode插件,而且它支持私有部署。我们今天就使用我们之前文档提到过的工程架构模板,去构建一个todolist应用,我们的api则是使用midway和serverless快速开发的。

如果你还不太了解我们之前使用的“工程架构模板”,那你可以看一下这篇文章

YAPI

准备了4个api供我们测试,它们都是隶属于List模块,api的源码在这里,我们需要在yapi平台上把这些api进行登记。
我们新建了一个测试项目,并且新建了一个list分类,同时新增了4个api:

1. /v1/list get
2. /v1/list post
3. /v1/list delete
4. /v1/list put

WX20211021-213731.png

我们list模块类型声明如下:

export interface List {
  id: string;
  title: string;
  content: string;
}

export type AddItem = Omit<List, 'id'>;
export type UpdateItem = List;

比如说新增的api,在post方法下,我们需要传递title,content,返回一个新增成功的id,这是一个很常见的业务场景,我们在yapi定义一下。

1634827748418.jpg

这个时候就需要体现出社区的强大了,在社区中有类似yapi2typescript的浏览器插件,所以我就fork一份,再插件之上重新修改了interface名等&新增了controller,modle层代码片段,如果你需要安装这个插件,你可以到这个仓库查看源码

我们就可以在页面下面看到,如下的类型提示:

WX20211025-170349.png

然后我们就可以copy到我们的工程中进行使用,这个时候你可能会问,yapi社区里有很多to typescript的方案,比如说vscode或者命令行工具,为什么要使用浏览器插件?出于以下几点原因,我使用浏览器插件:

  1. 不依赖IDE,让团队能更好的统一
  2. 不过度依赖yapi,大多数生成方案强绑定yapi,通过api去和本地type diff,这样不容易去单独修改type,难以和临时变化的api协调。

我们通过vscode命令model-init-type 去生成一个list.d.ts文件内容, 然后把yapi的类型提示进行粘贴:

namespace TListApiModel {
  interface ReqAddList {
    /** 列表标题 */
    title: string;
    /** 列表内容 */
    content: string;
  }

  interface ResAddList {
    /** 数据id */
    id: string;
  }
}

export default TListApiModel;

然后我们就使用命令快速实现一下,list模块的model层和controller层:

// model api
import useRequest from '../../hook/useRequest';
import TListApiModel from '../../../typings/model/api/list';
export default class ListApiModel {
  addList(params: TListApiModel.ReqAddList): Promise<TListApiModel.ResAddList> {
    return useRequest({
      url: '/v1/list',
      method: 'POST',
      data: params
    });
  }
}
// controller
import TListApiModel from '../../typings/model/api/list';
import ListApiModel from '../model/api/list';
export default class ListController {
  private apiModel: ListApiModel;
  constructor() {
    this.apiModel = new ListApiModel();
  }
  addList(params: TListApiModel.ReqAddList) {
    return this.apiModel.addList(params);
  }
}

测试

enjoy模板新增了jest,我们可以直接使用jest对功能进行测试,如下:

// tests/model/api/list.test.ts

import ListController from '../../../src/controller/list';

describe('addList', () => {
  const controller = new ListController();
  it('添加参数测试-1', async () => {
    await controller.addList({
      title: 'test',
      content: 'nihao'
    });
  });
  it('添加参数测试-2', async () => {
    const result = await controller.addList({
      title: 'test2',
      content: 'hello?'
    });
    console.log(result.id);
  });
});

运行npm run test tests/model/api/list.test.ts

WX20211025-172728.png

文章源代码预览

vue3-vite2-ts-template

托管地址: github-vue3-vite2-ts-template

  • [x] 使用最新版本的 vite 和 vue3
  • [x] antdv 真正意义上的按需加载组件以及组件css
  • [x] git 提交前的 lint-stage+husky 校验和美化代码(prettier), 多人协作风格统一
  • [x] 开发预设 eslint 校验和自动修复以及 Editorconfig
  • [x] 自带开发常用依赖,antdv, axios, day, querystring...
  • [x] 适合中小项目的 typescipt 的 mvc 风格架构
  • [x] 工具方法贯彻 hook 风格,且预装 vueuse
  • [x] scss 基本工具库封装,页面和页面无需引入,直接使用预定义的全局变量/函数
  • [x] vite/rollup 打包优化
  • [x] storage,cookie TS版本的模块化方案
  • [x] 预设 Pinia 状态管理的模块化以及类型声明
  • [x] 预设开发环境的 vite-plugin-mock
  • [x] 预设自动装载路由 vite-plugin-pages
  • [ ] SSR/CSR 优化
  • [ ] 业务组件/type 类型文档自动生成,且在启动开发服务器时,自动打开 doc
  • [ ] 动画方案
  • [ ] 预装业务常用的 webcomponents 组件(团队自己开发组件库)

命令

命令含义
dev快速启动本地开发服务器
lint带有--fix 的 eslint 校验
prettiereslint-prettier 的美化代码命令
preparenpm install 自动执行的 husky 安装命令(不使用的请忽略)
lint-stage对 git 暂存区的文件进行操作,源于 lint-stage 插件
buildvite 内置的打包使用 rollup,此模板自带打包优化
serve本地预览生产环境的程序

启动/打包 命令

命令含义
dev:test快速启动本地开发服务器(test 环境)
dev:prod快速启动本地开发服务器(prod 环境)
build:test打包(test 环境)
build:prod打包(prod 环境)

技术栈:

  1. vue3
  2. vueRouter4
  3. pinia
  4. typescript

命令行

通过安装Tool,来可视化地使用模板,因为仓库中的模板大多数都不会全部用到,你可以通过tool去按需引入它们

npm i enjoy-project-tool -g

创建模板

enjoy create

当然,作为模板的伴生工具,我还会继续维护并且持续提出新的feature来减轻我们开发负担

Tool是使用TS开发的,如果你感兴趣可以提pr,这是Tool的仓库

类型文档/组件文档

文档待补充,暂定使用

  1. dumi作为组件库文档

代码提交

旧版本的husky和新版还是有很多不一样的,所以如果你以前用过husky那么你要在代码提交这里做更多逻辑的话,可以去看看最新的文档。

模板中只拦截了pre_commit这个钩子,目标就是在pre_commit的时候对代码进行lint和自动修复以及美化,而且仅要对暂存区的文件lint,所以使用了lint-staged。这个组合太常见了,有需求的开发者可以再这个上层定义一些有趣的功能提pr。

还有一个需求是校验git commit message的规范,但是对于小团队来讲,校验这个规范没有太大必要,也暂时不会对团队带来好处,所以爱鼓捣的可以去鼓捣哈。

可以推荐团队成员使用 git-commit-plugin-vscode

vscode 开发小指南

推荐使用 Volar 插件进行开发,如果你的 IDE 是 Jetbrains 系列的,那么你可能不太需要这个插件,如果你是 vscode 推荐使用 volar。使用 volar,不仅可以在 vue 开发上和
jetbrains 的表现一致,还可以得到更完善 vue3 的支持,甚至非常新/在草案的语法糖都能够快速享受到。

下载volar地址

此模板对于vscode有天然的支持,如果你使用vscode,就能使用模板自带的vscode配置,比如说保存自动lint&fix&prettier或者其他有意思的功能。

  1. 有那么一点智能的代码模板

模板中自带了若干个vscode的code-snippets,snippets将会持续更新,它和模板深度贴合,可以帮助你摆脱繁琐的开发。下面就一一描述几个snippets的作用:

  • model-init-type

初始化@types/model/api的提示工具,自动声明命名空间以及导出

  • model-init-api

初始化model下的api类,自动引入与之匹配的type类型声明文件以及其他可能用到的依赖

  • model-init-cache

初始化model下的cache类,自动引入与之匹配的type类型声明文件以及其他可能用到的依赖

  • controller-init

初始化控制器类

  • vue-init

初始化vue页面/组件

AntdV 开发小指南

传统的 antdv 的按需加载,都会使用 babel-plugin-import 这个插件进行按需分析然后自动引入,但是 antdv 中有很多嵌套的父子组件:

<a-menu>
  <a-menu-item></a-menu-item>
</a-menu>

由于内部设计原因,无法使用这个插件进行按需导入。最主要的是我们已经使用了vite,本身就带有按需导入,我们只需要处理他们的css的按需引入即可。所以使用了2个插件:

  1. vite-plugin-components
  2. vite-plugin-style-import

第一个插件主要帮助我们自动识别模板中用到的组件,实现自动引入,也就是说我们使用antdv这样的组件库的时候,不需要全量引入,甚至不需要手动的import就可以自动实现按需引入,如图:

而且脚手架内置了按需引入css的逻辑,所以antdv本身的设计原因导致引入css问题开发者也不需要担心。
第二个插件主要是辅助第一个插件做按需引入css逻辑的。第一个插件做的按需引入css有些许问题,比如说antdv里面有很多api调用的组件,比如message,通过message方法调用一个组件,这个时候css不生效,就需要使用第二个插件进行处理。

对于message这样的api组件的css不生效的原因很简单,第一个插件仅仅是解析template用到的组件然后自动引入css,但是无法处理import进来的api组件,所以需要第二个插件做处理。

开发指南

这一块根据自身团队成员的习惯会逐步调整,所以这里的介绍会经常更改。

这套微不足道的架构足以应对中小APP,也是非常简单的,主要就是mvc+ts风格。如果你阅读完整个模板文档之后,你会发现很多东西都做了模块化,把业务划分开了,这也是目前团队开发没有注意到的一点,自身开发完爽是爽了,另外一个人维护就要惨了。各种配置,api都找不到,组件/组件参数也找不到,可能为了快速开发,都会去复制老项目和其他页面的代码;这虽然也是一种“复用”,但是总归来说并不是标准的。所以只有将业务划分开,才能快速定位具体核心代码,才能快速复用。

类型

src/@types

像大部分工程一样,把能抽离的type都尽量都抽离到了@types这一层,这一层也暂时根据需求划分了以下几个内容:

  1. controller
  2. model
  3. hook
  4. store

里面最重度使用的应该是model,我们在model模型中根据业务定义了很多ts,比如user.ts:

namespace TUserApiModel {
  type ReqLogin = {
    captcha: string;
    password: string;
    username: string;
    uuid: string;
  };

  type ResLogin = Promise<
    ActionResult<{
      token: string;
    }>
  >;
}

export default TUserApiModel;

这两个就代表了model里面api层(后面会详细说明model里面的api),使用Req和Res作为前缀也就是请求和响应的类型,那么我们定义好之后,在整个工程中我就可以这样使用类型:

TUserModel.ReqLogin

那么同理,types文件夹中像store,hook这样的,也是根据业务划分,去定义类型的,这里就不再过多阐述了。

模型

src/model

目前model分为2个含义:

  1. api
  2. cache

前端大部分的数据来源都包含到了,api模型定义了不同业务的api方法,比如user.ts:

import useRequest from '../../hook/useRequest';

export default class UserApiModel {
  async login(params: TUserModel.ReqLogin): TUserModel.ResLogin {
    return await useRequest({
      url: `${params}`,
      method: 'get',
      options: {
        authApi: true
      }
    });
  }
}

useRequest是我们自定义实现的hook函数,我们通过这个hook可以发起请求,那么你可以看到在这个类中定义了login这个方法,入参类型就是TUserModel.ReqLogin, 返回类型就是TUserModel.ResLogin,这个类型都是我们在@types定义的。

再比如说我们搭配kurimudb做了缓存的模块化,最常用的缓存插件也预装好了,我们可以在model里面去写这样一段代码:

/model/cache/user.ts

import { Models } from 'kurimudb';
import { LocalStorageDriver } from 'kurimudb-driver-localstorage';
import { CookieDriver } from 'kurimudb-driver-cookie';

export class UserLocalStorage extends Models.keyValue {
  constructor() {
    super({
      name: 'user',
      driver: LocalStorageDriver
    });
  }
}

export class UserCookie extends Models.keyValue {
  constructor() {
    super({
      name: 'user',
      driver: CookieDriver
    });
  }
}

我们在这里定义了2个kurimudb类,一个是localstorage一个是cookie,我们可以在这里新增一些方法或者直接导出给controller用,因为即便你不新增方法也可以使用kurimudb内置的函数。

我们拥有kurimudb这样的库可以解决存储模块化的问题,我们不用关心这个缓存的key是否被使用过,只需要设置好唯一的name值,它就能给我们提供一组方便调用的api。另外kurimudb还有sessionstorage和indexDB的插件,如果业务需要可以快速的安装,然后声明一个新的类导出即可使用。

控制器

src/controller

在模板默认自带了一个user.ts例子,我们在上一个model中说明了apiModel和cacheModel,这里的controller就直接引入它们。并且在controller暴露入口。

import UserApiModel from '../model/api/user';
import { UserLocalStorage, UserCookie } from '../model/cache/user';

export default class UserController {
  private localStorageModel: UserLocalStorage;
  private cookieModel: UserCookie;
  private apiModel: UserApiModel;

  constructor() {
    this.apiModel = new UserApiModel();
    this.localStorageModel = new UserLocalStorage();
    this.cookieModel = new UserCookie();
  }
  async login(req: TUserModel.ReqLogin): TUserModel.ResLogin {
    return await this.apiModel.login(req);
  }
}

控制器我们还可以对api/cache获取的数据做处理,比如说,后端返回的数据格式前端不便直接展示,我们应该在controller需要做一层转译,比如像这样:

transform(): { text: string; value: string }[] {
    const data = {
      '0': '小明',
      '1': '小红'
    };
    let _arr = [];
    let key: keyof typeof data;
    for (key in data) {
      _arr.push({
        text: data[key],
        value: key
      });
    }
    return _arr;
  }

视图(.vue)

以vue来举例,我们如何在视图优雅的调用controller?并且如何使用@types定义的类型来巩固我们的组件?

import TUserApiModel from '../../@types/model/api/user';

const login = async (params: TUserModel.ReqLogin) => {
  await userController.login(params);
};

// 调用login函数
login({
  captcha: "",
  password: "",
  username: "",
  uuid: ""
})

当调用login函数时候,提供了与ReqLogin不符合的数据结构,是会出现报错的。同理,我们调用cache也是一样,需要在controller把cache封装一层暴露给vue即可。

环境变量

可以根据业务需要,建立业务相关的 env 环境(模式)。 vite-模式文档

以下是根目录默认提供了 3 个环境文件,对应了本地,测试,生产环境

  1. .env
  2. .env.dev
  3. .env.prod

内容示例: 根据业务需要进行配置

VITE_APP_API=
VITE_APP_SECRET=

那么同理,如果业务需要额外增加新的自定义环境变量,则需要在 src/vite-env.d.ts 中重新定义类型:

/// <reference types="vite/client" />
interface ImportMetaEnv {
  VITE_APP_API: string;
  VITE_APP_SECRET: string;
  // 新的环境变量的定义写这里
}

Mock

使用vite-plugin-mock来做本地开发的mock,模板暂时没有内置生产环境的mock。

// vite.config.ts
viteMockServe({
  localEnabled: true //是否开启本地的mock功能
}),

定义mock api:

// /mock/user.ts

import { MockMethod } from 'vite-plugin-mock';
export default [
  {
    url: '/api/get',
    method: 'get',
    response: (res: any) => {
      return {
        code: 0,
        data: {
          name: 'this is mock name'
        }
      };
    }
  }
] as MockMethod[];

其他的库

  1. dayjs
  2. axios
  3. vueuse
  4. kurimudb
  5. query-string