防止/重构条件链

开发 JavaScript 应用程序时最常见的代码异味之一是过多的条件链接。在这篇文章中，我想讨论如何通过架构和代码来防止这些情况。

目录

1. 简介
2. 理解条件链
3. 条件链的问题
4. 重构条件链
5. 通过架构防止条件链
6. 前端开发最佳实践
7. 结论

什么是条件链？

过多的条件链是 JavaScript 应用程序中常见的代码味道。本文探讨了如何通过改进架构和编码实践来预防和重构这些情况。

条件链是过多的逻辑运算符，用于在函数或方法中表达条件。让我们看一个使用 React 应用程序的示例：

正如您在上面的示例中所看到的，存在一系列三个条件，仅决定此代码的呈现方式。
条件是：

1. 如果体育列表有元素，则应渲染默认元素；
2. 如果组件的加载状态为true，则应该渲染一个加载骨架；
3. 如果体育列表中没有元素，则应呈现空状态。

这段代码主要有两个问题：

1. 当我们检查数组的长度并使用“&&”运算符时，我们告诉 JavaScript 如果存在与数组长度相关的值，它应该渲染组件。如果没有数组，则该值应该为 null 或未定义，但是，如果数组存在且其长度为零，则将呈现数字零而不是元素，因为您要求 javascript 呈现链接到数组的长度。
2. 不需要使用链来控制这两个元素的渲染。在渲染组件的“默认”状态之前添加条件将是处理这种情况的更优雅的方法。

重构

话虽这么说，上面代码的重构版本是：

这是使用 JavaScript 逻辑运算符处理条件链的多种方法之一。正如你在上面的代码中看到的，我使用了一种非常规的方法来解决代码的条件过剩问题。

这个！！ JavaScript 中的运算符用于将值强制转换为布尔值。它利用了 JavaScript 具有真值和假值的事实。第一个！运算符对值求反，将真值变为假值，将假值变为真值。第二个！再次求反，得到原始值的布尔表示。这通常用于根据字符串、数字或对象等值的真实性或虚假性将其转换为布尔值（true 或 false）。

例如：

!!“Hello”的计算结果为 true，因为非空字符串为 true。
!!0 的计算结果为 false，因为 0 为 false。

通过架构决策来防止这种情况发生

您不能将此视为规则，但在大多数创建条件链的情况下，多余的条件会尝试解析和处理动态值，因为如果您正在处理静态值，则实现往往会变得更加简单和直接。

当你对数据库建模时，你必须对软件的依赖关系有一些担忧。

人们通常通过 IT 大学学习来学习这种依赖性研究，但我会举例说明。

软件的依赖有两种：

1. 功能依赖项 - 这些依赖项直接影响用户，因为它们是用户与之交互的功能，例如按钮、屏幕、输入、表单等。
2. 非功能依赖项 - 这些依赖项通常不会被普通用户注意到，因为它们主要是后端依赖项，例如错误处理、条件、业务规则、验证等。

防止前端过度控制

您的后端必须负责系统的所有逻辑部分，因此，大部分功能依赖项必须由后端功能处理，而不是由前端屏幕或用户交互处理。

当你开始开发一个新功能并了解它需要什么才能工作时，例如道具、接口和参数，你必须记住什么是必需的，什么是可选的，什么是不可以的使用过。

您必须使用上面的示例作为开发会话期间不应执行的操作的示例。正如你所看到的，这个接口只有可选参数，但我怀疑这个组件只会附加“可能”的变量。

在开发组件并将大量令人困惑的代码推送到前端应用程序之前，您需要了解组件应该如何工作。如果您只决定：组件将使用什么以及不使用什么，则无需处理许多条件，会更容易。

经过更好的考虑，你会想出这样的东西：

现在接口只有必需的参数，这些参数肯定会在应用程序内的组件生命周期中使用，而没有许多永远无法像以前的组件一样定义或使用的可选参数。

结论

预防和重构条件链可以生成更干净、更易于维护的代码。通过了解组件的需求、在适当的情况下将逻辑转移到后端并设计清晰的接口，您可以显着减少前端代码中对复杂条件链的需求。

---

照片由 Unsplash 上的 Samsung Memory 拍摄

以上是防止/重构条件链的详细内容。更多信息请关注PHP中文网其他相关文章！