| theme | background | class | highlighter |
|---|---|---|---|
seriph |
/1920x1080.jpeg |
text-center |
shiki |
前端规范是前端软件工程实施方案指导性规范
旨在规范化前端工程；减少Bug，提高代码质量；使团队代码更接近业务的表达方式；提高团队共识
撰稿人：Qingo
从常见前端工程分类的角度先分析工程特点
- 业务管理系统 - 数据逻辑复杂性工程
- 移动网站 - 用户体验优先型工程
- 小程序 - 一触即达的快速入口
- 可视化大屏 - 丰富多彩的全貌数据展示
- 复合型大型网站 - 大型综合性工程，电商网站等
数据逻辑复杂性工程
- 数据逻辑性强 - 不同的业务实体通常拥有全周期的数据管理事务，复杂的数据状态管理
- 数据查询多 - 业务实体全属性的大列表查询
- 数据录入多 - 数据入口多，录入方式多，一般有表单录入，文件导入等
- 数据展示多 - 地图、图表展示
- 权限复杂 - 角色设计较为复杂，不同的角色拥有不同的权限
- 页面同质化强 - dashboard、list、detail等类别，交互统一
- UI库选型 - 选择功能强大齐全的UI库
- 第三方集成 - 地图、图表等
- 常见业务页面的封装 把常见的页面封装成常用组件
用户体验优先型工程
- UI还原度要求高 - 侧重于用户体验，要较高的还原UI
- 自定义组件 - 组件定制化要求高
- 偶尔需要表单操作 - 数据录入不多，偶尔需要一些数据录入
- 社交属性多 - 需要集成微信等平台
- 集成能力 - 需要集成一些大厂的平台能力，如支付等
- 使用css方案 - 集成定制化更好的css方案
- 使是平台SDK - 需要关注平台的文档更新
- 各小程序平台差异 - 考虑使用成熟的跨平台框架
丰富多彩的全貌数据展示
- UI还原度要求高 - 侧重于用户体验，要较高的还原UI
- 交互较浅 - 一般不会有特别复杂的交互，展示偏扁平化
- 数据表现形式多样 - 以图形、图表、动画等形式展示数据
- 固定的屏幕尺寸 - 如果需要适配多种屏幕，适配比较麻烦
- 使用css方案 - 集成定制化更好的css方案
- 使用可视化技术和框架 - echarts、d3、svg等技术在开发中有时候效果很好
兼顾数据逻辑复杂性工程和用户体验优先型工程
- UI还原度要求高 - 侧重于用户体验，要较高的还原UI
- 交互的复杂度高 - 组件定制化要求高
- 权限复杂 - 角色设计较为复杂，不同的角色拥有不同的权限
- 数据逻辑性强 - 不同的业务实体通常拥有全周期的数据管理事务，复杂的数据状态管理
- 社交属性多 - 需要集成微信等平台
- 集成能力 - 需要集成一些大厂的平台能力，如支付等
最困难的开发问题
- UI还原度要求高 - 需要定制好更高的css框架
- 交互的复杂度高 - 组件间关联度高，需要定制组件，需要设计更为合理的组件结构
- 数据逻辑性强 - 需要设计更为合理的数据逻辑状态
- 统一的代码规范
- 统一的框架，包管理工具，项目结构，代码提交标准
- 统一的CSS系统
以《庄子·养生主》中，庖丁解牛的道理为比喻
- 第一层：熟能生巧 - 指定更加标准的工程约定，使其工作更轻松过，包括统一框架，统一的第三方库，统一的包管理工具，统一的项目结构，统一的代码提交标准
- 第二层：使团队成为更薄的刀 - 把常见的业务常见二次封装成已用的公共组件，如经典的条件查询列表页等
- 第三层：复杂的场景需要认真设计 - 复杂的UI，复杂的组件，复杂的数据逻辑需要认真设计
- 第四层：完成复杂设计和实现后，需要归档和分享 - 自定义UI，自定义组件，自定义数据逻辑需要整理文档，提取为公共资产
把基础的技能标准化
- 工程语言 - Typescript
- 工程工具和工程目录 - pnpm、项目结构、monorepo项目，vite
- 统一框架 - 建议使用react，统一生态
- 统一第三方库 - UI库，等
- 统一的CSS方案 - 建议使用css in js，比如tailwindcss、uncss等
- 编码规范 - 使用统一的eslint工具进行格式化代码，和校验代码格式
- 代码提交标准 - 使用git分支方案，使用git commit 提交规范
把常见的业务常见二次封装成已用的公共组件
- 视图组件和数据层分离 - 视图组件尽量保持独立无副作用，数据注入层保持独立，实现业务代码和组件库代码的解偶
- 视图组件命名 - 业务表达的公共组件中尽量不适合很特殊的业务字段来明明state、props、method、event等，尽可能的按照字段在在布局习惯来命名属性，尽可能的按照交互习惯方法和事件，比如header、footer、title、onClose等
- 使用monorepo项目把公共组件做分离 - 使用pnpm的monorepo项目的方式来管理多包
- 使用context管理状态 - 尽量不适合第三方状态库，保证公共组件的独立性
- 多组件组合的形式封装复杂业务 - 对于负责的公共组件，使用多组件组合的形式封装
- 使用统一的状态管理库，mobx、redux，或者直接使用context进行封装
- 针对复杂的业务需求，设计更合理的业务状态结构，避免使用过多的useState代码
- 如果直接使用hooks管理状态，封装自定义业务hook
- 针对复杂的业务需求，设计更合理的组件树
- 针对需要非常深的组件的应用场景，进行业务层的组件封装，建议不依赖第三方，使用context的方式注入
- 如果使用context的形式注入状态，选择更合理的组件节点上进行状态注入，原则上保证所有共享状态的组件都方便使用的同事，最小化的形式注入
- 一般情况下，状态的作用域（注入域）可以分为：全局域、业务模块域、UI组件域
- 设计合理的副作用 副作用一般是指对组件外部的状态进行管理，或者组件外部功能调用
- 梳理清楚功能、子功能、功能流程和规则 - 产品设计中有三大图：功能结构图、信息结构图、产品结构图
- 规范业务实体类 - 信息结构图类似于DDD中的实体中的属性，在前端开发中大部分是通过后端API获取到的数据，建议使用Typescript中的interface来规范
- 实体属性展示规则 - 一般情况下，实体属性会管理很多业务展示的规则，和属性含义相关，还有属性的异常处理
- 合理的拆分组件 - 根据视图需求反推组建的拆分，功能的展示需要使用组件来表达，功能执行需要组件的生命周期钩子（LifeCycle Hooks），或者组件的事件中触发；合理的功能拆分是合理的拆分组件的基础
- 功能执行流程 - 复杂的流程需要认真梳理文档
- 实例化需求 和产品经理、测试沟通测试用例，整个功能需求可以实例化
自定义UI，自定义组件，自定义数据逻辑需要整理文档，提取为公共资产，可以回头完善使团队成为更薄的刀
- 复杂组件结构使用excalidraw文件绘制结构图，表达设计的设计树，表明其中的 状态、属性、交互等
- 复杂规则使用mermaid绘制流程图 表达流程和规则，mermaid是markdown的图形扩展语法
- 数据逻辑使用mermaid绘制类图 表达设计的数据逻辑
- 使用自建npm镜像 来存储自定义的私有包
- 持续关注相关公共资源的需求和迭代