:::info 💁🏻‍♂️ 持续更新中 … :::

良好的前端应用应该是：

  • 性能高，体验好 UX
  • 简单性，易维护 DX
  • 工程强，效能高 DX

为了实现上述的目标，这里陈列一些 @Arno(surfacew) 日常研发过程中总结的一些经验和原则。

整体设计原则

  • Design First, Then Implement. 设计优先！先做宏观的设计。
    • 根据业务需求，做基础 lib 和工程选择
    • 考虑状态的设计 React 应用状态管理随记，使用合理的框架、lib 拆解应用状态
    • 考虑 UI Blocks 的拆解的方式，比如：
      • 视图类组件（有应用级别的状态的组件）
      • 业务组件（有业务性质的基础组件，比如公司内部的选人组件）
      • 基础组件（通用无业务性质的组件比如 AntD）
    • 关注数据的不可变性设计，对特定的场景有奇效
  • 适度关注当前前端应用的「可演进式设计」，关注外部业务、技术变化对当前架构的冲击以及未来的应对策略。
  • 底层业务库配置单元测试，尤其是需要跨业务使用的底层单元需要保证质量，有 DevOps 跑单测、集成测试或者 E2E 测试的机制。
  • 研发可扩展的系统，坚持 IoC & DI 等设计方法的使用 ，甚至引入微内核架构，具体可以参阅： 🎛 剖一剖 Inversify.js IOC & DI 实现机制 以及 深入浅出前端做控制反转与依赖注入。

  • 面对复杂系统的业务逻辑，坚持使用 OO 的编程范式，做结构设计和功能实现，且强制使用 Typescript 作为编程语言。

    高性能原则

  • 视图组件（FunctionComponent）尽量拆解得比较细，不要合成一个大函数，因为函数中 useState() 的使用会导致整个节点 Render 函数执行，影响性能。

  • 缓存策略，需要在每一个层面去思考，时常放心里。缓存(Cache) & 客户端缓存，适度使用支持缓存的库，比如 React Query 最佳实践 去实现高频场景下的合理缓存。
  • 始终打开 React DevTools 上的 RenderHighlight 功能，以可视化检测 DOM 的真实渲染情况，一旦发现有重复绘制，或者绘制的区域不精准（冗余绘制），立即进行针对性优化。
  • 关注包体积，使用 Treeshaking 等机制，剔除冗余依赖，并谨慎引入外部依赖。

稳定性原则

  • 使用成熟的高质量的开源库，但需要注意使用版本锁，类似 yarn.lock。
  • Hook 使用的时候，尤其需要注意 防止循环依赖的发生，需要及其细心地处理 Hooks 的依赖。
  • 注意 XSS 保护 ，非授信内容需要转义输出。

可维护原则

  • 统一团队的 代码编写风格 。
  • 统一团队的 代码组织风格：目录组织、项目组织（MonoRepo）等。对于大型项目而言，适度地拆解做技术、业务的自治也是合理的，寡头式的应用不利于大型团队运作。
  • 团队内合理地使用 设计模式、设计原则 等，改善程序的结构、行为的组织，进行有效地沟通形成共识，统一设计语言。
  • 视图和逻辑分离的基本原则 需要严格遵循（这一点说起来简单，然而大家经常不遵循）。
  • 文件长度控制，很多时候复杂度的根源，来源于偷懒模式下不做切割和分离，就导致文件的冗长。500 行，Maybe 是极限了。

工程类

  • 使用好代码工具，提升编程效率，比如 VSCode 和它无敌的插件生态。
  • 团队维护统一的 React Boilerplate，并提供渐进式升级的机制，将设计原则和 BP 融入其中。
  • 对于需要多个团队频繁维护一个复杂的 Web 系统，可以考虑引入 💠 微前端概览(MicroFrontEnd) 架构，提升工程协同效率和代码隔离，又不失 SPA 级别的体验。
  • 在不影响稳定性的情况下 适度使用新的工程技术，比如：Vite / esbuild / swc 等提升开发效率。
  • 关注接口联调的效率，使用 GraphQL 或者一些接口生成和 Mock 以及自动生成 *.d.ts 的数据模型定义文件。

Ref