【获奖名单公布】yapi-to-all 接口文档驱动开发

我们拿到需求文档，与产品以及设计同学选定我们本次需求需要消费的组件，与后端同学确定我们的接口定义。首先我们根据接口文档定义请求方法，以及 ts 类型。然后用我们的状态管理库结合请求方法，完成状态变更方法的编写，然后将方法和状态传入对应的页面，在业务组件库以及基础组件库里选择以及组合组件组合完成业务场景代码的编写，在页面内对应的组件消费我们之前定义的方法完成本次需求的开发。

这个高度重复的编码流程完全可以抽象出来，用代码生成的方式完成各个环节的组合和关联。

下面我们将先优化以及选择我们消费的物料，然后再组织优化整理后的物料，完成开发流程的整理和抽象。

对于请求状态处理，我们选择 useRequest hook

ahooks 库中的 useRequest 方法是一个非常实用的 hook，可以帮助我们更加便捷地进行数据请求和状态管理。它的主要好处包括：

useRequest 方法的主要功能包括：

关于请求模块，我们选择 umi-request：现成方案；以及经过改造过的适用于小程序的请求方案

主要好处：

避免手写重复的请求和错误处理逻辑，提高代码复用和可维护性，同时也可以提高请求和响应数据的处理效率和质量。还具有灵活的配置和扩展性，可以根据自己的需求来进行定制和扩展，满足不同场景下的请求和响应处理需求。主要功能：

众所周知，组件是业务提效以及业务线基建的重中之重，我们通常遇到的会有以下几种：

我们通过通用业务场景的方式，完成组件之间的关联，形成场景模版池；再进一步通过关联我们约定的接口定义将接口和场景模版代码关联在一起。

我们将 useRequest 和 service 定义整合在一起，每次定义一个请求的方法，这个方法就会挂一个 useRequest hook 整合了请求的状态，这样我们不需要像之前需要分别定义再做传参调用，而是直接内聚在一起，让业务同学根据场景决定是否使用。完成了请求方法和状态定义的聚合。

我们将每一个请求的参数以及返回值的 ts 定义都聚合在一个 type 上，而且也做了平铺处理，这样所有请求方法的 ts 定义在都在同一级可以直接获取到，没有嵌套也让类型的消费更简单。参数类型名为 ServiceTypes[methodName + ‘Params’], 返回值类型名为 ServiceTypes[methodName + ‘Response’] ，使用上，只要引入对应页面的 ServiceTypes 文件名，就可以直接消费对应方法的定义。

配置文件

目录：路由关联 service 对应的 service, 这里请求相关的配置都在页面路径下的 generateServices 里，这样就会在对应的页面路径下生成一个 service 文件。如下所示，每一个路径都关联了一个 generateServices 的数组属性，这种关联确保了具体页面需要消费的接口生成在对应的页面。做到页面代码与请求代码的内聚。

我们可以通过 template 去选择我们的业务场景，如果是有约定固定消费数据格式的 template，还可以直接帮助我们完成接口和页面的关联。

如果不加 template 参数，不生成模版代码，只生成请求函数，请求状态，类型定义：

生成的抽屉提交表单页代码

我们在对应页面的任何地方，在需要时不论时发出请求还是引用 ts 类型，都可以直接引用一个聚合变量，便捷消费。

下面是设计图：

我们的配置文件，是在路由里新增生成示的 generateService 字段，在里面配置接口地址，以及需要消费的模版名，以及格式化的函数去转换接口文档提供给我们的请求返回参数。

根据这些配置信息，再根据对应是后台还是微信小程序选择消费我们的组件库对应的 demo 模版，以及对应的请求模块完成我们的业务代码：请求函数，状态管理，ts 定义，视图页面。最后按照团队代码风格的注入方式和顺序完成业务的开发。

下面是流程图：