其他工程实践

滥用事件总线的危害

事件名称难以追溯，增加了代码复杂度、可维护性降低
调试难度大

业务代码分层习惯

├─assets 静态资源
├─service 业务逻辑封装
├─components 组件
  ├─business 业务组件
  ├─common 通用组件
├─constants 常量
├─store 全局状态
├─pages 页面
├─types 通用类型
├─utils 工具

使前端能够脱离后端进行独立测试

集成 mockjs 等工具，使前端能够脱离后端独立的进行测试，模拟后端各种请求报错以及所有其他情况

npm 脚本命名

同一系列行为的脚本，命令行参数、环境变量有差异，用冒号区分，比如

"scripts": {
  "build:test": "tsc && vite build --mode test",
  "build:prod": "tsc && vite build --mode production",
}

前置操作的处理

如登录、获取用户信息、权限检查等任务，放在根组件（App.tsx、App.vue）中执行，执行结束再渲染路由组件，保证业务接口能正确获取参数

小程序：

小程序入口组件不会渲染任何内容，
例如 Taro 框架，根组件必须同步返回 props.children，
所以对前置操作的处理，可以将首页设置为一个 loading 页，在 loading 页中显示加载中且进行前置操作后，
再跳转到业务页面（为 loading 页设置如 redirectUrl 参数设置跳转页面）。

不建议在本地构建部署代码

应使用 devops 系统

前端项目的一般部署流程

获取代码：从代码仓库获取项目代码，并切换到待部署的分支或版本
安装依赖：安装项目构建所需要的依赖包
源码构建：使用构建工具对项目源代码进行构建，生成产物代码
产物打包：将部署所需的代码（通常指的是构建后的产物代码，如果是部署 Node 服务则还需要其他目录与文件）打成压缩包
推送代码：将待部署的文件或压缩包推送至目标服务器的特定目录下，如果是推送压缩包的情况，还需执行解压
重启服务：在部署 Node 服务的情况下，在代码推送后需要进行服务重启

本地部署的优势

快速：不需要获取代码、安装依赖这几个步骤
构建失败能更方便查找问题

本地部署的劣势

溯源难
环境一致性：不同开发人员的本地依赖包版本可能存在差异，导致打包结果并不严格一致；本地环境和部署代码的目标服务器环境之间也可能存在差异；导致项目代码的稳定性无法得到保障

例如对于一个 Node 项目而言，在一个 NodeJS 低版本环境下构建的产物，在 Node 高版本环境下就有可能启动异常

其他

第三方库按需加载
移除生产环境的控制台打印
动态 polyfill
通过判断环境变量的方式，区分执行环境差异代码，借助 DefinePlugin 将环境变量静态嵌入客户端代码
尽量不要污染全局 window 对象
通过封装解决浏览器差异兼容性问题
为项目配置代码引用路径别名 alias
项目不要添加任何与开发环境强耦合的设置（比如某个地方必须借助 vscode 的某个插件才能运行）
禁止安装私人依赖包
使用 Webpack Bundle Analyzer 分析包大小组成
函数遵循单一职责原则

只导入类型，使用 import type

import type { DependencyList, useEffect, useLayoutEffect } from 'react';

想要在 chrome 移动设备模拟器上添加某个自定义设备型号，需要知道该设备的分辨率
```
console.log(document.body.clientWidth, document.body.clientHeight);
```
开发环境 node 和 npm 版本需要一致，因为不同版本 node、npm 行为不一样