适用于任何技能水平的开发人员的可扩展 React 架构
当我们中的许多人考虑可伸缩性时，我们通常会考虑应用程序在大量并发用户的情况下快速执行的能力。虽然这是可扩展性的一个方面，但大多数问题远在应用程序达到这一点之前就出现了。我们经常遇到来自模棱两可的代码模式和代码结构的问题。当应用程序的这个基本部分没有建立或难以理解时，许多过程变得更加困难。需要付出很大的努力才能取得最小的进展。
构建 React 应用程序有无数种方法。我的目标不是教你“最好的”方法，而是帮助你思考如何创建一个适合你需要的架构，无论你是在处理个人项目还是大型组织的应用程序。通过创建可扩展的架构，您应该能够：
- 提高开发速度
- 减少错误
- 减少精神开销
- 改善沟通
- 创建一个不会崩溃的强大应用程序
- 减小应用程序大小并提高性能
- 轻松加入新成员
- 简化维护
模块化设计
在我们看任何与代码相关的东西之前，让我们看一下其他一些工程产品，以了解我们如何在我们的软件中实现相同的原则。
例如，如果我们看一辆汽车，我们将不同的组件或模块组合在一起以创建一辆完整的汽车。我们有轮子、引擎和车身等等。只要新发动机与变速箱以及汽车的其他部件兼容，我们就可以将我们的汽车发动机拆卸并更换为其他发动机。如果您必须更换轮胎，您知道您只需要取下旧轮胎，然后装上新轮胎。汽车的其他部分不受此更改的影响。
An engine is made up of modular parts
如果我们从汽车放大到发动机，我们可以看到汽车发动机也是由许多更小的部件组成的。同样，只要引擎的组件兼容，它们就可以互换。例如，我们可以拆下水泵，然后换上另一个。虽然发动机作为一个整体是一个复杂的机械部件，但每个单独的部件只需要知道它是如何相互连接的。我们可以以同样的方式思考我们的软件。我们的应用程序不是通过能量传递，而是传递数据，但每个单独的组件只知道它自己的功能。
A PC is also made of modular, interchangeable parts
使用可互换组件构建的产品的另一个示例是 PC。我们可以轻松移除和更换 PC 的不同部分，并且它仍然可以工作。移除硬盘驱动器并用具有更多存储空间的硬盘驱动器替换它是很常见的。如果我们再看一下硬盘驱动器本身，它也是由其他更小的组件构成的。
您能想到任何其他由可互换组件制成的产品吗？
用户界面剖析
Search Results Page
现在，在 React 应用程序的上下文中，让我们看一下 Medium 的 Web 应用程序。我们可以看到，有 3 个不同的组件：左侧的侧边导航、中间的文章结果和右侧的推荐内容。
Sidebar Navigation
如果我们进一步分解这些部分，我们可以看到这些部分是由更小的组件构建的。例如，在侧面导航中，我们有徽标、图标部分和用户徽章。虽然徽标和用户徽章无法进一步细分，但图标部分由单独的图标和分隔线组成。
Article Results section
如果我们看中间部分，我们有搜索结果标题、选项卡导航和文章结果卡。同样，这些可以分解成更小的单个组件，直到它们无法进一步分解。这是进一步细分的文章。
Example of how Article could be broken down
花几分钟时间，看看哪些较小的组件构成了推荐的内容部分。这是我如何分解的：
Recommended section components
文件夹结构
既然我们已经将应用程序分解为单独的构建块，那么我们可以如何组织我们的应用程序有无限的可能性。然而，最重要的是我们保留了交换组件的能力。
这是一个示例，说明如何构建这样的结构：
Organization of basic components vs specific components
作为基本构建块的每个组件都包含在“组件”文件夹中。这些名称是通用的，并且准确地描述了组件是什么，而不是它的作用。
Page is made up of 3 sections, clearly understandable in the code. These components are specific to the page, and therefore exist within the “SearchResults” folder
较大的组件放置在“页面”文件夹中。顶层是“SearchResults”页面，它由前面定义的 3 个部分组成。代码和文件夹结构都清楚地传达了这个层次结构。没有其他组件需要了解这些部分。它们是直接构成 SearchResults 页面的 3 个组件。
SearchResults 文件夹包含构建组件所需的所有内容，并且没有其他组件需要引用构建它的较小组件。
现在，如果我们打开 SideNav，我们可以看到组成它的组件。 SideNav 由放置在“components”文件夹中的通用 Logo 和 Avatar 组件构建。它还具有侧边栏独有的 IconList。然后在 SideNav 文件夹中创建 IconList 文件夹以显示这一点。
由于 IconList 仅由“components”文件夹中的组件组成，因此它没有任何后代文件夹。我们也可以通过查看代码清楚地看到构建 IconList 所需的组件。
根据我如何分解上图中的 ArticleResults 部分，您认为文件可以如何组织？如何编写代码来传达这一点？以下是我的组织方式：
Let’s assume we have an array of article objects called “articles”
现在让我们看一下文章文件夹。在前面的图片中，我发布了一个如何将文章组件分解为更小部分的示例。
为了匹配示例，它可能如下所示：
或者，为像 Title 或 Description 这样小的组件创建新文件可能是多余的，实际上它们只是可重用的 Text 组件。在不破坏文章中任何组件的情况下，文章文件的外观如下：
然而，在这两个示例中，代码的模块化都得到了维护。可以对任一文章文件进行更改，而不会影响代码库的任何其他部分。它们都由包含在“组件文件夹”中的最基本组件组成。
剩下的由你决定
这些歧义是存在的，由您决定。你想为你的按钮创建一个带有 prop 配置的文件还是 4 个单独的按钮文件？如果您只有 2 种按钮类型怎么办？有 1 个带道具的按钮，还是有明确定义的 2 个按钮更好？
Example of using 1 button component for the different button types
如果我们添加更多使用与我们之前创建的相同文章组件的页面怎么办？我们可以将上面创建的 Article 组件移动到“组件”中，或者最终编写重复的代码。
虽然后者违背了 DRY（不要重复自己）原则，但有许多不同的应用程序、用例、业务需求和开发人员需求。您和您的团队需要自己决定这些细微差别。你做出的每一个决定都有权衡，你需要权衡利弊。
但是，在构建时考虑到模块化，您永远不会被束缚在过去做出的决定中。您可以根据需求的变化自由改变主意。
如果你想创建一个新的侧边栏，你可以简单地删除旧的，并用一个新的替换它。如果你想改变一个按钮，你应该知道每个使用该按钮的组件，并且可以做出相应的改变。
更进一步
许多测试和样式库允许您保持模块化。测试和样式仅由包含它的文件夹编写和使用。
您的应用程序中可能需要更多抽象组件。也许，路由器或状态管理库。有太多的可能性要经历，但你应该保持同样的心态。您希望能够以最小的开销添加或交换这些东西。如果你要彻底检修你的路由器，你只需要改变你的组件连接它的方式。虽然像这样的任务通常很乏味，但组件之间不应该存在复杂的互连，这会使这变得异常困难。
结论
这个话题不是一刀切的规则。还有无数其他的组织策略，您可能会发现它们更有用。然而，重要的是您和其他人能够理解您编写的代码。编写代码应该是有趣和有益的。我们应该集中精力尝试解决问题，并创建我们可以引以为豪的代码。我希望你能从这篇文章中找到价值。请不要犹豫，在评论部分提出任何问题或提供反馈。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/11732/30520315
标签：架构,开发人员,代码,应用程序,React,文件夹,构建,组件,我们 From： https://www.cnblogs.com/amboke/p/16652761.html