自VUE3开始项目开发以来，业务法规在逻辑上分为块，包装成企业** Hook **功能已成为我们业务开发方面的标准实践 - 将相同业务逻辑的分离关注包装子块自然不需要说更多。但是，经过一段时间的开发，我们发现在处理返回值类型和不同业务功能的参数类型时存在一些问题。
让我们在引入组合API时首先查看演示代码：
我们可以发现：
官方演示代码使用JS示范。如果您使用TS，我们需要补充参数的类型。通常，我们将编写代码，如下所示：
由于TS的自动类型，我们不需要声明的声明类型。TS可以推断该类型。
依赖性，代码如下：
我们手动声明的类型，这种类型必须与** UserRepositories中的存储库**一致。
编写代码时的类似方式。
乍一看，上面的代码没有问题。这是非常合理的。每个人似乎都这样写。但是事实并非如此。如果您在一段时间内使用VUE3+组合的API，则自然会发现一些问题：类似于上述代码中的**存储库变量，实际上，它是一个非常接近业务的变量UserePositoryNamesearch也是一个与业务紧密绑定的钩子功能，因此应收敛而不是在处理方面发散
如何理解类型的收敛性和分歧？
以此为例，如果修改了中间的类型，则如果我们需要手动修改参数存储库中的参数存储库** ** **在** userepositorynamesearch中，则我们认为该类型的类型about被分散。如果我们不需要手动修改，它们可以自然保持一致，那么我们认为类型正在融合。
收敛类型的写作看起来代码如下：
一些学生可能会说这很简单，我们提供了单独的陈述或单独的陈述，类似于以下内容：
这些方法符合融合的类型，它们是正确的，但似乎还不够简洁。
当函数返回值较大时，每个返回值声明类型的类型或声誉包含函数的所有返回值。它具有开发成本和维护成本。这是TS类型推理。因此，我们可以编写一个非常干净，简单的代码，而无需做太多冗余语句：
在上一部分中，我们已经知道TS类型推理可以自动推断该函数的返回值类型，那么我们只需要获取推断的类型即可。可以简单地基于TS工具类型实现：
目前，在中间，我们不需要重新定义：
介质中的字符串可以自动获得代码的支持。无需手动输入。
首先，没有任何模型是通用的，只有最好的是最好的。一些学生可能对此方法有疑问。“这两个函数的返回值类型和参数类型会耦合吗？”
确实是这种情况。如果我们编写公共功能，则此功能没有深厚的耦合业务方案，只是为了重复使用，那么该类型可以保持独立性，并且可以与其他类型没有耦合。这也是一种融合。
因此，我在本文中解释的开发模型更适合于业务的深层耦合。因为该模型确实更适合我们的业务开发。
本文是关于如何在业务开发中优化代码的一些简单思考，欢迎大家留言讨论?
原始：https：//juejin.cn/post/7096367390400708644