前端代码重用一直是一个非常重要的话题，也是一个非常困难的话题。在前端开发中，我们经常遇到许多重复的代码，例如，我们经常在不同页面中使用相同的组件或相同的功能。目前，我们需要考虑如何重复使用这些重复的代码。在本文中，我将与您分享前端代码重用的一些本质。

1。组件重复使用

我们可以在其中找到许多出色的前端组件库，例如ANT，UI，VANT等。这些组件库提供了许多出色的组件。并不难发现这些组件不会在一夜之间启动。它们必须被许多人使用和测试，并且非常普遍。例如，按钮，选择框，数据库，表单等。我们可以直接使用这些组件。这些组件库的优点是它们提供了许多现成的组件，我们可以直接使用这些组件，并且这些组件库已被许多人使用和测试，因此非常保证它们的质量。此方法实际上是重复使用组件的一种方法。

因此，回到我们自己的项目，我们应该如何重用组件？实际上，我们可以封装一些常见的组件，然后在需要的地方引用它们。例如，我们可以将一些常见的形式组件封装，然后在需要的地方引用它们。这种方法可以大大提高我们的发展效率并降低我们的代码量。

例如，我们有一个一般的接触组件，可以在许多页面上使用。目前，我们可以封装此组件，然后在需要的地方将其引用。这种方法可以大大提高我们的发展效率，降低我们的代码量并降低维护成本。一个可能的代码示例如下：

代码语言：

复制

import React from 'react'; import { Input, Button } from 'antd'; //通用的联系人函数式组件 //渲染一个联系人面板，包含姓名、电话、身份证号等信息，敏感信息自动打码 function Contact(props) { const { name, phone, idCard } = props; //敏感信息打码 const maskIdCard = idCard => { return idCard.replace(/(\d{4})\d+(\d{4})$/, '$1****$2'); }; return (

); } export default Contact;

2。逻辑重复使用

实际上，在前端领域，由于其复杂的相互作用，许多业务在某些操作（例如PC和移动设备）中存在很大差异。因此，重复使用前端组件也可能是不现实的，即使该组件是强行制作的。重用还将增加组件的复杂性并增加维护成本。

即使是当前流行的前端框架，也无法完全解决此问题。有些人可能会说，例如，芋头或Uni-App解决了一组代码来解决多终端问题？但是实际上，这些框架还通过一组代码生成多末端代码，而不是真正的逻辑重复使用。

当我们真的想编写PC页面和移动页面时，我们会发现许多接口组件无法重复使用。例如，我们可能在移动页面上有一些滑动操作，并且在PC页面上进行了一些单击操作。此外，PC本身还有更多可用的空间，并且在一个屏幕上显示更多内容，而手机本身的可用空间较少，并且在一个屏幕上显示的内容较少，这在布局上也有很大的差异。

例如，在Uni-App开发应用程序和迷你程序中逻辑上的重复使用实际上很难，因为应用程序和迷你程序的交互方法不同。应用程序是本地交互方法，它们都可以在基础功能中使用。有一些差异，因此我与我接触的大多数团队都有一个针对应用程序和迷你程序的页面。例如，页面的目录结构可能是这样的，它们将严格区分应用程序和H5。

代码语言：

复制

├── src │ ├── pages │ │ ├── HomePage │ │ │ ├── app.vue // 为App编写的代码 │ │ │ ├── miniprogram.vue // 为小程序编写的代码 │ │ │ ├── h5.vue // 为H5编写的代码 │ │ │ ├── index.vue // 通用的代码 │ ├── models │ ├── services │ ├── utils ├── package.json ├── tsconfig.json ├── README.md

其中，.VUE代码示例如下：

代码语言：

复制

因此，我们看到在某些复杂的业务逻辑方案中，尤其是当交互差异情况很大时，用一组代码解决多终端问题是不现实的。通常，实现应该是多组代码，这正是一种编码。语言，由多个目的分别实施。因此，我们需要专注于逻辑重复使用。

尽管在前端接口上实现前端交互式代码可能很难，甚至在某些情况下也不是现实的，但我们仍然可以在逻辑重复使用中进行。例如，我们可以封装一些常见的逻辑，然后将其引用在需要的位置。例如，我们可以封装一些常见的请求逻辑，然后将其引用需要的位置。这种方法可以大大提高我们的发展效率并降低我们的代码量。

接下来，让我们谈谈业务逻辑重复使用的姿势。实际上，在前端研发领域，我们或多或少地接触了某些设计模型，例如MVC，MVVM，MVP，MVI等。这些设计模式都旨在解决一些常见的问题。例如，MVC是解决数据和视图之间的分离问题，MVVM是解决数据和视图之间双向绑定的问题，而MVP是解决视图和业务逻辑之间的分离问题。 MVI将解决分离观点和国家的问题。

以下是：

架构图如下所述：

架构图如下所述：

架构图如下：

架构图如下：

我今天要谈论的前端业务逻辑重复使用实际上可以参考或直接使用上述某些模式，例如MVP。我们专注于创建一般的M和P层，然后参考不同页面中的这些一般M和P层。层，以便可以实现逻辑多路复用。这种方法可以大大提高我们的发展效率并降低我们的代码量。

那么，我们如何具体实施呢？假设我们现在有三个结局：

我们如何创建这样的通用M和P层？这测试了我们抽象业务的能力。我们需要抽象业务逻辑，然后封装这些抽象业务逻辑，然后在不同页面中引用这些抽象业务逻辑。例如，我们可能需要结合一些设计模式，例如，我们可以使用观察者模式来封装一些常见的业务逻辑，然后在不同页面中引用这些常见的业务逻辑。我们还需要遵循一些设计原则。我认为最重要的是单一责任原则。我们需要抽象业务逻辑，然后封装这些抽象的业务逻辑，然后在不同页面中引用这些抽象业务逻辑。另一个是打开和关闭的原则。我们需要抽象业务逻辑，然后封装这些抽象的业务逻辑，然后在不同页面中引用这些抽象业务逻辑。

好的，经过这么多交谈后，我感到有些干燥，准备开始编写代码。让我们看一个特定的示例，例如，我们现在有一个企业用户管理流。

可能设计的业务逻辑是：

等等，我不会继续写作。接下来，我们将上述业务逻辑抽象，然后封装这些抽象业务逻辑，然后在不同页面中引用这些抽象业务逻辑。我们的目标是使这层成为该层。请注意，该层几乎完全实现，并且不依赖任何前端框架。这样，即使您的使用Uni-App开发，您也会使用VUE，H5和PC。是的，此M层也可以使用。

代码语言：

复制

├── src │ ├── models │ │ ├── EnterpriseUserManager.ts // 你的M层类 │ │ ├── index.ts // 导出所有的models │ ├── services │ │ ├── authService.ts // 包含企业认证、个人用户实名认证等方法的服务

│ │ ├── userService.ts // 包含员工管理、权限审批等方法的服务 │ │ ├── enterpriseService.ts // 包含企业信息管理、联系人管理等方法的服务 │ │ ├── sealService.ts // 包含印章管理的方法的服务 │ │ ├── index.ts // 导出所有的services │ ├── utils │ │ ├── api.ts // 包含API调用的工具函数 │ │ ├── index.ts // 导出所有的utils │ ├── app.ts // 主应用文件 │ ├── index.ts // 应用入口文件 ├── package.json // npm包管理文件 ├── tsconfig.json // TypeScript配置文件 ├── README.md // 项目说明文件

代码语言：

复制

class EnterpriseUserManager { // 这些属性可能需要根据你的业务需求进行调整 private enterpriseId: string; private userId: string; constructor(enterpriseId: string, userId: string) { this.enterpriseId = enterpriseId; this.userId = userId; } // 企业认证 async enterpriseCertification(certificationInfo: any): Promise { // 这里应该包含实际的认证逻辑 } // 个人用户实名认证 async individualCertification(certificationInfo: any): Promise { // 这里应该包含实际的认证逻辑 } // 法人授权 async legalPersonAuthorization(authorizationInfo: any): Promise { // 这里应该包含实际的授权逻辑 } // 员工管理 async manageEmployee(employeeInfo: any): Promise { // 这里应该包含实际的员工管理逻辑 } // 权限审批 async permissionApproval(approvalInfo: any): Promise { // 这里应该包含实际的审批逻辑 } // 企业信息管理 async manageEnterpriseInfo(info: any): Promise { // 这里应该包含实际的企业信息管理逻辑 } // 联系人管理 async manageContact(contactInfo: any): Promise { // 这里应该包含实际的联系人管理逻辑 } // 印章管理 async manageSeal(sealInfo: any): Promise { // 这里应该包含实际的印章管理逻辑 } } export default EnterpriseUserManager;

然后，我在我的业务页面中引用此M层。例如，我在企业身份验证流中的页面及其 Vue中介绍了此M层，而H5侧的代码可能看起来像这样：

迷你计划

代码语言：

复制

H5结束

代码语言：

复制

import React, { useEffect } from 'react'; import { EnterpriseUserManager } from '@/models'; function EnterpriseCertificationPage() { useEffect(() => { const enterpriseUserManager = new EnterpriseUserManager('enterpriseId', 'userId'); // 使用enterpriseUserManager进行企业认证 enterpriseUserManager.enterpriseCertification(certificationInfo) .then(response => { // 处理认证成功 }) .catch(error => { // 处理认证失败 }); }, []); return ( // 你的页面组件 ); } export default EnterpriseCertificationPage;

前端页面的重点是视图的渲染，而不是商业逻辑的处理。这种方法可以大大提高我们的发展效率，并且不言而喻的维护线是不言而喻的。

自动代码生成

当我们练习代码重复使用时，我们发现了一个问题，即代码规范问题。我们应该根据哪种模型编写代码，以促进后续的业务逻辑，以重复使用多个目的。我们可能需要一个标准模板定义一组可重复使用的框架，然后业务逻辑的开发人员只需要根据此模板编写代码，然后可以实现可重复使用的业务逻辑。

那么，我们应该如何做特定的做法？我们可以使用两个工具和VS代码来实现自动代码生成。 VS代码是生成项目模板的工具，是用于生成VS代码插件的工具。这很合适。考虑一下，右键单击面对文件夹，单击以生成代码，然后生成标准的业务逻辑代码框架。然后，研发朋友只需要遵循此框架即可。通过编写代码，您可以重复使用业务逻辑。

这是一个示例模板：

代码语言：

复制

├── generators │ ├── app │ │ ├── index.js │ │ ├── templates │ │ │ ├── index.js │ │ │ ├── index.test.js │ │ │ ├── miniProgram.js │ │ │ ├── h5.js │ │ │ ├── pc.js │ │ │ ├── README.md │ │ │ ├── package.json │ │ │ ├── .gitignore ├── package.json

一个良好的可重复使用的业务逻辑模块需要自动测试，这可以确保业务逻辑和业务逻辑可维护性的稳定性。在.js的设计中，需要遵循设计模式的一些原理，并尝试成为面向接口的编程，而不是以实现为导向的编程，这可以确保业务逻辑的可扩展性和业务逻辑的可维护性的可扩展性。

在这里，每个块的外部依赖关系可能不同，需要处理的业务逻辑也不同。如何设计此模板更优雅？在这里，我们必须对业务逻辑进行一些抽象，然后将这些抽象的业务逻辑封装以在模块之间连接。请注意，它必须是抽象的。具体的实现应留给业务逻辑的开发者以实施。如果最后有差异，那么如果没有抽象，这绝对是不可能的。

这是/.js的模板示例。在这里，我们在MVP层中为M层的模板提供了一个示例：

代码语言：

复制

// 抽象策略类 class AbstractStrategy { validateData(data) { // 通用的数据验证逻辑 } handleError(error) { // 通用的错误处理逻辑 } log(message) { // 通用的日志记录逻辑 } // 有明显差一点可以写一个抽象，具体在不同平台端 中实现 businessLogic(data) { throw new Error('This method must be overridden'); } } class MiniProgramStrategy extends AbstractStrategy { businessLogic(data) { // 小程序的业务逻辑 // 可以使用 this.validateData, this.handleError, this.log } } class H5Strategy extends AbstractStrategy { businessLogic() { // H5的业务逻辑 } } class PCStrategy extends AbstractStrategy { businessLogic() { // PC的业务逻辑 } } // 工厂类 class StrategyFactory { static getStrategy(platform) { switch (platform) { case 'miniProgram': return new MiniProgramStrategy(); case 'h5': return new H5Strategy(); case 'pc': return new PCStrategy(); default: throw new Error(`No strategy found for platform ${platform}`); } } } // 使用策略 const platform = 'miniProgram'; // 这个值可能来自用户的输入或者配置文件 const strategy = StrategyFactory.getStrategy(platform); strategy.businessLogic();

这是VS代码的示例模板：

代码语言：

复制

├── src │ ├── extension.ts │ ├── test │ │ ├── extension.test.ts ├── package.json

内部的文件是生成代码的模板。 .TS生成代码实际上是基于模板生成代码的节点fs。

总结

我觉得这些是关于前端代码重复使用的一些最新想法。前端代码重用是一个非常重要的话题，一个无法避免的问题，也是一个非常困难的问题。但是，尽管很困难，但我们总是会发现一些突破。例如，我们可以将整体分开，发现逻辑层可以在相对较大的规模上重复使用。然后，我们可以使用一些设计模式（例如MVP）来实现逻辑重复使用。 ，然后我们可以使用两个工具和VS代码来实现自动代码生成，以便我们可以更好地实现前端代码重复使用。

遵循我的官方帐户的旧代码冥想记录，并每天推动前端技术信息，为您提供对前端技术的深入解释，并使您成为技术专家。