React 的这种流行并不能使在项目中使用它的程序员免于糟糕的开发实践。React 使开发人员能够创建组件并在代码中再次重用它们，甚至将它们导入到其他项目中。如果不适当关注代码质量，不良的编程习惯可能会降低系统的可维护性，并将 React 的优势化为尘土。今天，我们将研究一些 React 反模式的例子，这些反模式的避免将帮助您确保 Web 应用程序的一流质量。

反模式存在哪些危险以及如何及时发现它们

编程语言和Web开发框架很棘手。看起来他们做了您希望他们做的事情，但问题是如何确保您以正确的方式使用它们。您可以导入所需的库，创建所需的组件，并在屏幕上呈现所需的所有内容，这并不一定意味着没有改进的余地。此外，这并不意味着如果您决定在其他地方重用某些组件，您的项目就不会分崩离析。

如果您创建了一段代码或组件，您或任何其他程序员以后可以毫不费力地重用，则表明存在良好的模式。如果代码易于查看、维护、导入和调试，则使用良好模式的机会甚至更高。我们可以将一切以相反方式工作的东西都视为反模式。即使是经验丰富的开发人员，如果不给予应有的关注，也可能成为反模式的受害者。
幸运的是，有一些迹象有助于检测 React 代码中的反模式。例如，当您使用此库构建 Web 应用程序时，您希望它的不同部分相互连接。它有助于确保当所有组件相互依赖时，整个应用程序具有所需的条件。例如，当您通过使用不采用依赖项数组的 useRef 挂钩来违反此规则时，会增加潜在问题的可能性，因此在这种情况下最好小心。

另一个例子是过度嵌套。例如，如果应用程序布局的细节需要，则创建具有子组件的父组件似乎很正常。子组件可以是另一个组件的父组件，依此类推。这个兔子的洞可以很深，这取决于你的 React 应用程序的复杂性。问题是，当子组件编号 10 中存在错误时，您必须遍历其父组件的整个树才能找到它的来源。

你最好避免的反应反模式的例子

当您使用太多嵌套组件时，您的代码可能会变得非常令人头疼。让我们来看看我们已经提到的一个例子，因为它经常出现在试图进入React JS 开发世界的没有经验的开发人员中。例如，你可以像这样嵌套你的 React 组件：

你可能会说，这里没有什么可担心的。毕竟，除了父组件之外，没有其他地方可以使用子组件。不幸的是，这种方法有一些隐藏的缺点。首先，您可能会面临一些性能问题。我们用了一个非常简单的例子，但在现实生活中，你的 React 代码可能包含几十个嵌套组件。每次需要重新呈现应用时，父组件都必须执行与子组件相关的代码。即使子组件没有要显示的新数据，父组件也会重复执行声明函数。代码具有的嵌套组件越多，在这个无意义的任务上花费的计算资源就越多。想象一下，如果您决定在其他项目中导入此代码，会造成多大的损害。因此，不要在其父组件中声明组件，这一点很重要。作为替代方法，您可以使用如下所示的内容：

低估复杂计算的结果是另一个习惯，你最好避免。假设你想要构建一个处理大数据并依赖于大量计算的应用。在这种情况下，您可能决定使用如下所示的 React 代码：

相信我们，这个组件执行了一些非常繁重的计算。问题是这种外观完美的代码可能会导致一些严重的性能问题。如果存在更改组件状态的操作，则即使没有新数据，也必须再次执行所有这些计算。如果您在 React 应用程序的不同部分中重用此代码，您可能会遇到一些严重的问题。幸运的是，您可以随时导入和使用useMemo钩子，该钩子可以记住先前计算的结果，并在没有数据更改的情况下避免浪费计算能力：

状态管理是 React 应用程序最具挑战性的任务之一，会影响可维护性和可伸缩性。为了避免不必要的复杂性，尽可能限制在状态中存储变量的意图可能会很有用。为此，您可以遵循派生状态的概念。这意味着您必须更喜欢使用可以动态计算的变量。例如，如果您有一个包含大量复选框的大型窗体，则可以通过遍历 items 数组并在每次需要重新呈现组件时筛选它们来确定其中一些复选框是否被选中。遵循派生状态修补程序是在进行新更改时使应用使用的数据保持同步的可靠方法。

结论

React 是一个非常强大的开发工具。像任何其他工具一样，它可以用来建造漂亮的东西，但在坏人手中，它可能会在项目中引入缺陷。即使一切看起来都很好，某些代码部分也可能由看似无害的反模式组成，从而导致性能降低和潜在的维护问题。好消息是，经验丰富的程序员非常了解它们，因此如果您决定与可靠的软件开发团队合作，则无需担心。