React 中的过度设计

React 简单易用，功能强大，是如今构建 Web 应用的首选之一。然而，能力越大，责任也越大。由于 React 的广泛使用，在寻找满足开发者需求的解决方案时，很容易找到大量结果，但最受欢迎的解决方案并不一定适用于所有情况。

在本文中，我将介绍开发人员倾向于盲目坚持的一些常见模式和工具，而不会评估它们是否真正适用于他们的特定用例。

使用库进行状态管理

别误会，正确的状态管理是构建可靠、可扩展且面向未来的应用程序的基础。在项目早期就考虑到这一点尤为重要，但在开始使用基于[此处插入一个流行的状态管理库]的模板之前，你可能需要三思。我这样认为有几个原因：

• 它迫使你以库的方式思考和建模你的应用程序，而不是做出能够更准确地反映业务现实的选择。你是使用 redux 还是 mobx（或者什么都不用）应该取决于它是否适合你的用例，而不是简单地取决于哪种更流行。

• 你的应用性能可能会下降。作为开发者，我们往往会忽略应用包大小和低端设备上的性能指标，但这最终可能会对用户与产品的交互方式产生巨大的影响。此外，如果使用不当，库代码过多可能会导致不必要的重新渲染，从而降低应用的响应速度。
  

• 归根结底，它需要你随着时间的推移学习、记录、传授、维护和升级新事物。这是决定是否使用状态管理库的关键因素：它是否能为你节省足够的时间，并从长远来看让你的工作更加轻松，以至于值得向每个加入项目的新开发人员传授它？你是否有足够的时间记录一个你采用不同做法的特定场景？你是否愿意因为一个重大变更而升级你的所有代码库？如果所有这些问题的答案都是肯定的，那就继续吧。

创建太多文件/文件夹

如果你之前用过像 Angular 这样的框架，你可能对创建几个文件和一个文件夹来组织独立的 UI 组件很熟悉。添加模块、路由文件、索引和服务，最终你会得到一大堆样板代码，才能让系统在任何特定场景下都能按照你想要的方式运行。样板代码本身并不是什么坏事，但有了 React，我们构建应用时就不需要这么繁琐的流程了。

现在，我并不是说你应该删除所有 .js 文件，把所有内容都放在同一个文件中，而是拥抱框架赋予你的灵活性，将帮助你创建更易于浏览的应用程序，从而更易于维护。React官方文档甚至鼓励这种做法，并为我们提供了一些在布局应用程序结构时需要考虑的指导原则。

为了避免不必要的嵌套/文件创建，我采取了以下一些措施：

• 不要在没有界限的地方设置界限：虽然人们普遍认为应用程序是由屏幕和组件组成的，但究竟是什么区分了它们呢？你今天认为的组件，将来可能会变成屏幕，反之亦然。只要你的领域明确规定某些内容应该归属于某个文件夹，就应该这样做。在需要之前创建额外的文件夹只会增加额外的工作。Dan Abramov 在本文中对此进行了更深入的探讨，他阐明了展示组件和容器组件之间的区别——但要小心！你实际上会找到一个免责声明，他在其中谈到了自撰写该文章以来他的观点是如何变化的。

• 利用钩子的强大功能：随着新的复杂组件逐渐成型，您可能会忍不住创建新文件，最终可能希望将逻辑相似的组件放在同一个文件夹中。但实际上，通过使用钩子来合理地复用逻辑，您可以避免所有相似但又各自独立的组件所带来的额外复杂性。

• 使用样式化组件：样式化组件在大多数情况下可以帮助将所有样式及其相关逻辑保留在同一个文件中。这在很大程度上取决于每个用例，但由于其灵活性以及在我的应用中设置、读取和维护的简便性，它们已经广受欢迎。

测试错误的地方

虽然，无论何时发布一款未来会持续开发的产品，构建一个强大的测试套件都是重中之重，但测试错误的地方可能会导致许多挫败感和时间浪费，尤其是在前端。让我们首先定义一下这些“错误的地方”是什么，以及哪些不是。

Kent Dodds 在《如何知道要测试什么》中写道

编写代码时，请记住，您已经有两个需要支持的用户：最终用户和开发者用户。同样，如果您只考虑代码而不是用例，那么开始测试实现细节就变得很危险。当您这样做时，您的代码现在有了第三个用户。

在这篇文章中，我们将讨论如何让“开发者用户”更满意。如果你能够编写能够在未来真正检测到错误的测试，你必然会更满意。如何做到这一点？通过以用户的方式测试你的应用，避免高投入/低价值的代码块，并编写简洁易懂的测试。

让我们逐一分析一下：

• 测试用户使用应用程序的方式：在这里我强烈建议阅读 Kent Dodds 的《测试实施细节》，他详细阐述了测试实施细节如何导致容易出错的测试，而这些测试实际上对于捕获错误并不是很有用。

• 避免高投入/低价值的代码块：如果您仅使用代码覆盖率作为衡量测试质量的指标（这本身也存在问题），您经常会发现一些依赖于第三方库的代码无法按预期运行，从而拉低了覆盖率。在这种情况下，您必须权衡该功能对应用程序的关键性，以及您需要花费在编码、维护以及在应用程序的多个部分复制该功能上的时间。

• 编写简洁易懂的测试：测试越简单、清晰、易懂，就越能反映出功能编写的水平。虽然你应该避免为了简化测试而让实现变得更加复杂，但如果你的测试能够清晰地描述功能片段的最终目标，那么新的维护人员可能会更容易阅读代码库并进行修改。

虽然编写完美的 React 代码并没有固定的规则，但遵循这些指导原则确实节省了我的时间，让我在职业生涯中避免了 bug 和不必要的会议。希望你也能从中受益。

你最喜欢的框架中是否存在过度设计的例子？你通常是如何解决这些问题的？欢迎随时与我联系，分享你的例子或提出任何问题！

照片由Unsplash上的Science in HD提供