关于前端:20212022我的前端最佳实践

41次阅读

共计 3317 个字符,预计需要花费 9 分钟才能阅读完成。

这两年播种了很多,在构建大型项目下面积攒了一些教训,尽管曾经融入在了日常开发合作中,但仍旧感觉有必要记录下来,心愿对其他同学造成一些参考。

(可选)Monorepo

One Team, One Repository, One Guide

Monorepo 是一个蕴含多个不同我的项目的繁多仓库,这不是必须的,但对于咱们团队来讲,从中受害良多。

对于开发者来讲,经常会遇到以下理论场景:

保护的多个组件库、配置库或工具库提供给多个业务我的项目应用

  1. 因为一个我的项目对应一个仓库,开发者须要操作多个仓库以及分支
  2. 须要推动每一个业务接入方降级,更改无奈及时扩散到其余我的项目

与这个问题相似的还有对立革新相干问题,如域名降级、根底库降级等等,一个我的项目对应一个仓库会导致此类场景很难推动,工作量大大增加。

流程反复建设

发包流水线,Gitlab CI 流水线等等,须要为每一个我的项目进行独自配置,存在很多反复工作。

通过 Monorepo 能够解决很多此类流程以及标准上的问题,整体团队达到统一与对立,升高沟通损耗,同时随着团队扩充以及我的项目的增多,模块抽离与复用变得非常容易。

笔者先前有过 Rush 的落地教训,在实际过程中,发现除了最根本的代码共享能力外,还该当至多具备三种能力,即:

  1. 依赖治理能力。随着依赖数量的减少,仍旧可能放弃依赖构造的正确性、稳定性以及装置效率。
  2. 工作编排能力。可能以最大的效率以及正确的程序执行 Monorepo 内我的项目的工作(能够广义了解为 npm scripts,如 build、test 以及 lint 等),且复杂度不会随着 Monorepo 内我的项目增多而减少。
  3. 版本公布能力。可能基于改变的我的项目,联合我的项目依赖关系,正确地进行版本号变更、CHANGELOG 生成以及我的项目公布。

如何抉择适合本人的 Monorepo 工具链?

  1. Pnpm Workspace + Changesets:成本低,满足大多数场景
  2. Pnpm Workspace + Changesets + Turborepo/Lage:在 1 的根底上加强工作编排能力
  3. Rush:思考全面,扩展性强

想要理解更多对于 Monorepo 的常识,能够翻阅笔者 Monorepo 系列文章:

  • 从 Turborepo 看 Monorepo 工具的工作编排能力
  • 利用级 Monorepo 优化计划
  • 基于 Rush 的 Monorepo 多包公布实际
  • Monorepo 中的任务调度机制

🗄️ 我的项目构造

就近准则:将组件、函数、款式、状态等尽可能地放在其被应用的中央。

除了以类型维度划分组件 components、函数 utils、状态 models 以及 hooks 等模块,业务开发中更多时候应该以性能 feature 为维度组织我的项目。

feature 是服务于某个业务模块的 components、models 以及 utils 等模块的组合,如果是没有具体业务属性相干的通用模块就放里面。

这是构建大型项目的较佳实际,在可维护性与可读性上获得了较好的成果。
目录构造如下:

.
└── src
    ├── assets # 通用动态文件
    ├── components # 通用根底组件
    ├── config # 我的项目环境变量
    ├── features # 我的项目个性性能
    │   ├── {feature1}
    │   └── {feature2}
    ├── hooks # 通用根底 React hooks
    ├── models # 通用根底 model
    ├── pages # 我的项目路由文件夹
    ├── services # 我的项目接口申请(个别应用自动化工具生成)├── types #全局类型文件
    └── utils #通用根底工具函数 

举荐浏览:

  • [React Folder Structure in 5 Steps [2022]](https://www.robinwieruch.de/r…)
  • bulletproof-react/project-structure

💅🏻 款式计划

举荐:Tailwind CSS + Styled Components

兼顾开发效率与视觉标准,优先应用 Tailwind CSS 解决款式,内置部门内视觉标准以及通用的款式计划。

遇到 Tailwind CSS 无奈笼罩的场景,如一些简单的伪类或笼罩第三方组件库的款式,请应用 Styled Components。

长处:

  1. 无需新建文件以及命名,配合主动提醒开发效率高
  2. 工具类与视觉标准对齐,页面还原度高
  3. css 不会收缩,打包体积小

毛病:

  1. 可读性可能较差。请正当进行组件拆分,抽离组件 或 renderXXX()

举荐浏览:

  • https://www.tailwindcss.cn/do…

🗃️ 状态治理

举荐:React Query + Unstated Next

服务端状态交由 React Query(或 SWR)治理,客户端状态共享基于 React Context 即可。

对于绝大多数应用程序来说,在将所有的异步代码迁徙到 React Query 之后,真正须要全局拜访的客户端状态通常是非常少的。

为了保障可读性,你更应该应用 Unstated Next 而非间接应用 React Context。

如果对客户端状态治理能力有着较强诉求,举荐 zustand,和 unstated-next 一样,都是很精简的状态管理工具,但设计简略,使用方便。

举荐浏览:

  • React Query: Does this replace client state?

📡 网络申请

举荐:暂无

除了最根底的封装 axios 以及 fetch 等网络申请库,还有两点须要重点关注:

  1. 主动生成相干 service 代码
  2. 接口变更同步

因为笔者应用的是公司外部计划,没有应用过开源计划,所以暂无举荐,只据说过 Pont,有趣味的同学能够一试。

🌲 分支标准

举荐:Trunk Based Development

分支标准须要联合以后团队的迭代节奏正当抉择。对于 Monorepo 以及迭代节奏稳固、不适度谋求灵便的团队来讲,举荐应用 Trunk Based Development 分支模型。

开发阶段:

  1. 从 master 拉出 feature 分支进行开发
  2. 开发完需要中的一个模块后提起 MR 并进行 Code Review 合入 master
  3. 反复 1 和 2,直到开发完所有模块

测试阶段:

同开发阶段统一

预上线阶段:

  1. 从 master 分支拉出 release 版本分支进行上线

hotfix:

  1. 从 release 版本分支拉出 hotfix 分支进行修复上线
  2. cherry-pick 对应的提交至 master 分支(可通过自动化工具实现)

长处:

  1. 操作简略
  2. 不便 code review。10 lines = 10 issues; 500 lines = looks fine
  3. 合码越早危险裸露越早,特地是在 monorepo 场景下,越晚合入 master,危险越大,可能别的我的项目某个依赖的变动导致本我的项目构建失败

毛病:

  1. 不够灵便,开发阶段就合入 master,后续难以拆分性能点上线,feature flag 落地较为艰难
  2. master 准入规范较高,须要通过严格的 CI 检测以及 code review

以上是举荐做法,但实际上往往不尽人意,以笔者目前团队为例,同一个业务我的项目存在了多个产品经理,产品经理的需要之间互相独立,然而会要求在同一天上线,同时心愿需要 A 不会因为需要 B delay 而 delay。

  1. 从 master 拉出 feature 分支开发
  2. 测试环境测试
  3. 预发环境测试
  4. 所有需要合入 master
  5. 整体回归测试
  6. 上线

Q:为什么有回归环节?

A: 因为同一天会上线一个我的项目的多个需要,所以提前合入 master 回归(个别提前一天)这一步是为了防止多个需要同一天上线合码导致的一些 BUG,故而有了这个环节。

Q:为什么预发环境测试完才合入 master?

A: 是为了最大水平防止某个需要呈现问题导致整体需要 delay,测完 PPE 根本曾经有保障了。

代理工具

举荐:whistle / lightproxy

应用代理工具时,开发者个别会关注以下内容五点内容:

  1. 动态资源代理
  2. 登录状态代理
  3. api 接口代理
  4. 接口 Mock
  5. 挪动端反对

构建工具内置的 proxy 往往无奈全面满足,笔者应用的是公司外部基于 whistle 开发的一个代理软件,开源工具能够试试 whistle 以及 lightproxy。

其余

通过 CI 流水线保障代码品质、主动发包流水线进步发包效率也是很有必要的,然而笔者都是基于 Monorepo 仓库前提进行落地,参考价值可能不大,就不具体开展了。

正文完
 0