大家好，我是LV。
「AI赋能前端研发」 是一系列的篇章，持续更新，总结了笔者在前端研发领域的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 // 存放业务组件的单元测试
通过 storybook 管理所有业务组件。
好处：1、基于storybook运行环境，能快速进行业务组件的开发；2、便于业务组件的统一管理维护，基于 storybook 示例文档，新人可以快速熟悉业务组件；
「2、拆分业务组件」
基于整个设计稿页面，按照模块的 「独立性」 和 「可复用性」 来拆分业务组件。
「3、定义 业务组件的 props」
业务组件的props决定了这个组件的功能，这也是正式开发代码前的第一步。
如何设计呢：「一进一出」；
一进：组件的运行和渲染依赖什么样的外部数据
一出：组件能够给外部提供什么数据
「4、根据定义好的props和代码规范编写代码」
在开发业务组件的步骤中，这一步开发人员花的时间最多，同样也是我们AI赋能的重点。
AI如何赋能
根据以上业务组件的开发流程，笔者早在去年中旬的时候，就探索了AI如何生成前端业务组件，详见：《【在公司前端项目中落地 ChatGPT】初探成果》、《【在公司前端项目中落地 ChatGPT】聊天式编程》
总结起来4步走：
「1、定义角色」
「2、投喂基础UI组件数据」
「3、描述业务组件的基本信息，开始生成代码」
「4、迭代优化」
ps：如上提示词原文件如有需要，可以链接笔者获取。
当然，上面是笔者在AI赋能前端早些时候的探索经历，现在已经有了更多新的洞察和落地方案。
不过这也我是探索AI赋能前端从 0 ～ 1 路上的历程，希望给大家一些帮助～
后续我们继续讨论如下内容：
基于基础组件库打造AI小助手、「循序渐进式」业务组件代码生成、「一劳永逸式」业务组件代码生成
欢迎链接笔者，AI赋能，共勉。
