【AI赋能前端研发】整洁的业务组件架构-易微帮

大家好，我是LV。

AI赋能前端研发 是一系列的篇章，持续更新，总结了笔者在前端研发领域的AI赋能的全流程。

上一篇章，笔者针对AI赋能前端研发，进行了全流程的分析，建议还没看过的同学先看上一章，详见：

上次提到，AI赋能的重点会围绕：从 0 ～ 1 开发业务组件这个步骤。

这个步骤的内容有点多，为了让内容更具有结构性，便于读者理解，也将会拆成一些个小节来说。

本篇咱们讨论：如何写出干净整洁的业务组件，以及AI赋能业务组件生成的早期探索经验。

建议收藏关注防失联，不多说，开始。

Clean Components

Clean Code —— 干净的代码。

不同的公司可能存在不同的 codding 规范，但是万变不离其宗。

简而言之：编写容易理解、修改、可维护的代码。

笔者在公司提出了 clean component ，目前已经在前端项目中落地，同时老项目的技术重构也也在推行新的 clean component 规范。

何为 clean component？

其中最重要的一个原则就是：服务端状态和前端状态 分离。

服务端状态和前端状态

先来看一段代码，这种类型的代码大部分的前端同学可能都不陌生。

使用mobx或者redux来管理所有的数据状态，包括服务端状态（请求api拿到的数据状态）和前端状态（组件的loading、visible等）。
在任意组件中请求api、对接联调数据，然后再将这些状态通过 inject 等方式注入到任意层级的组件中。

存在的问题：

1、前后端状态数据混合在一起，随着项目的扩大，状态将会越来越多，同时这些状态会在各种组件中被赋值及消费，导致数据的维护越来越复杂。

2、在任意的业务组件中请求接口，对接服务端数据，功能职责耦合严重，导致业务组件强依赖于服务端的接口数据、接口的任何变更会直接影响到大范围的业务组件。

优化后的方案：

规范前端页面开发的工作流：业务组件开发 -> 数据对接联调。

其中包含一个最基本的原则：服务端状态和前端状态分离

所有业务组件均可独立运行
业务组件中不能直接请求api数据，需要触发接口请求的地方通过props回调给到外部对接层。

这样做的好处：

功能职责单一，整体的数据流向十分清晰：对接层请求数据给到业务组件层，业务组件通过props回调触发对接层的数据变更。
技术迭代维护很简单，以我公司的一个场景举例：

由于后端将所有的 restful api 迁移到了 graphql，因此前端也需要配合修改所有的api对接。

如果是在以前：由于服务端状态数据和前端状态数据混合在了一起 ，同时在很多业务组件中都直接对接了api，因此我们需要找到每一个直接对接了 api 组件，然后逐个替换为 graphql，还得要保证服务端数据的变化不会影响到耦合在一起的前端状态数据

现在：由于服务端状态数据和前端状态数据分隔开来了 ，所以我们不需要关心业务组件，只需要在对接层将 restful api 换成 graphql 即可。

那么，基于这个原则，如何从 0 ～ 1 开发一个整洁的业务组件呢？

业务组件从 0 ～ 1 的开发步骤

1、明确业务组件的代码规范

千人千面，不同的公司有不同的代码规范，甚至同一个公司的不同项目可能也有不同的规范。

但是要想一个项目具有长期的可维护性，代码规范至关重要。

如下为我司业务组件的规范示例：

代码结构

StorybookExample // 业务组件名称
├─ index.ts // 仅仅将组件内容暴露给外部
├─ interface.ts // 定义组件内部用到的所有类型，包括 interface、type、enum等
├─ StorybookExample.stories.tsx // 组件的storybook文档，包含组件的使用示例
├─ StorybookExample.tsx // 组件的主体逻辑，如果组件太大可以拆分为其它的文件
├─ styles.ts // 组件所有的样式资源存放在此，使用styled-components来编写
├─ helpers.ts // 如果存在一些工具函数，那放在此处
├─ StorybookExample.test.tsx // 存放业务组件的单元测试