Skip to content
On this page

008 前端开发周报

我要买鼓, 我感觉我能行

本周内容

  • baseViteIe11 实践一周

baseViteIe11

unocss 很爽, 但传统开发还是不太一样

基于 unocss 开发还是很爽的, 一直开发一直爽. 无需再忍受 tailwindcss 的构建速度了, unocss 无与伦比.

由于很久没接触传统的前端开发了, 跟后端对接的时候问题就出来了.

  1. 一坨 className 导致后端维护困难. 主要原因是因为前端产物并不是最终产物, 后端拿到手后还需要大刀阔斧的嵌入动态语言. 这就导致每次样式修正都必须由后端再捋一遍 html. 所以需要引入 @unocss/transformer-directives 让 unocss 支持 @apply, 乖乖的给每个 dom 起名字, 样式写在独立的 scss 文件中吧.
  2. 图片更新问题. 随时间的推移部分页面图片会有所调整, 本来可以由后端直接替换文件更新部署即可, 但因为小于 4k 的图片被转换成了 base64; 大于 4k 的图片名带上了 hash. 如果每次都由前端打包后交给后端, 后端不仅要替换图片, 还要捋一遍 html. 所以为了省事, 可以修改 vite 的配置 build.assetsInlineLimit 调整 base64 的问题; 可以修改 vite 的配置 build.rollupOptions.output 调整 hash 的问题; 也可以把图片都扔到 public 目录中让 vite 不做任何处理.
  3. css/js 文件名 hash 问题. 每次前端打包, 变动的文件会生成新的 hash, 导致后端还是要捋一遍 html 文件中的引用. 所以需要修改 vite 的配置 build.manifest 生成 hash 文件对照表, 后端读取一下这个文件即可做到自动更新.

无论上面哪个问题, 看似都是过时的开发方式. 但不论什么开发方式, 项目跑通上线, 正常运营是第一位的.

unocss 并不是 tailwindcss / windicss 的同类产品

起初使用 unocss 只是因为 tailwindcss 的构建太慢了, 一个项目下来每次调整都要构建几分钟. 但随着不断深入, 发现 unocss 并没有那么简单, 官方把她定义为 css 引擎还是有原因的.

比如这里, 本打算自己搓一个识别模式, 因为中间遇到问题而去发了个帖子. 在回复中发现其实她已经支持这模式, 而且写的也相当优雅.

所以, 不论是官方适配的能力, 还是自定义扩展的能力, 都是无与伦比的.