构建 React 应用程序——我从作为一名 Web 开发人员的经验中学到的东西

React 一直以来都因其较短的学习曲线和易于使用的 API 而广受欢迎。但如果你已经使用这个流行的 JavaScript 库一段时间了，你可能会同意我的观点——如果你不注意它的结构，它很快就会变得一团糟，难以维护。

在开始我的第一份工作之前，我有一些自由职业者的经验，但除了在网上或开发过程中接触到的知识之外，我对最佳实践和架构了解不多。即使作为一名自由职业者，我也没有后期工作中需要处理的大型应用程序的经验。正是在那时，我开始更加关注架构。一开始，事情有时会变得有些混乱——主要是因为我比以前更加注重自己的代码——这很明显，因为我现在是团队的一员，而不是一个独立的自由职业者。

于是我开始浏览 GitHub、在线文章、论文和书籍。随着我越来越多地大规模使用 React，我意识到

强大、可扩展且易于维护的 React 应用程序的关键是架构。

这适用于任何应用程序或软件，但对于 React 来说，抽象比其他库/框架要困难一些。这种情况直到Hooks 出现才有所改变——但由于它仍然比较新，而且大多数应用程序仍然使用旧版本的 React 构建，因此我们暂时不讨论它。此外，它还有很多需要改进的地方；在使用过程中有很多需要注意的事项。

到目前为止，我认为我构建 React 应用程序所遵循的原则也适用于 Hooks！因为我的重点是可扩展的 Web 应用程序架构，而不仅仅是 React。

我们先快速看一下整个设置，然后我会逐步讲解，并解释为什么采用这样的结构。项目的根目录如下所示：

该src目录（当然，它将包含我们应用程序的所有源代码）的结构如下：

你可能首先会注意到，并且可能会感到疑惑——如果你没有，我建议你再看看——config我们的项目中有两个目录。不，这不是错误！原因（极其）简单。

一个 Web 应用程序需要两个配置目录？！为什么呢？

根目录config包含与构建相关的所有配置文件 - 例如我们应用程序的 webpack 配置或我们可能使用的任何其他捆绑器、环境文件和其他配置。

你可能还会注意到，它是嵌套的，并且 webpack 配置位于其自己的目录中。这使得配置更有条理，更易于管理。这看似微不足道，但随着应用程序规模的扩大，构建过程也可能会变得复杂——这就需要一个井井有条的独立目录。此外，这还能让你在使用时更加安心——在生产环境中部署应用程序时，你最不希望看到的就是一堆杂乱的配置文件！👀

config我们文件夹中的另一个目录src用于存放与应用程序相关的配置，即与运行时相关的配置。它可能包含 json 文件（或任何其他文件），这些文件可能会影响应用程序的行为或功能。虽然根据你的需要，这可能需要也可能不需要，但对我来说，大多数项目中都有这个文件夹。

但是等等，resources和assets目录又是怎么回事呢？assets 不也是我们 React 应用的“资源”的一部分吗？

嗯，assets这里的目录仅用于存储图像和其他媒体，呃，

而 ，resources则用于存储我们的 Web 应用程序可能需要的数据，例如常量和其他静态数据，这些数据基本上没有任何或没有太多相关的逻辑。您还可以添加一些小方法来返回数据，这些数据可能被格式化为特定需求，并且/或者对它们执行一些小操作，供我们应用程序的各个部分使用。顺便说一句——相信我——这将使您的代码更加简洁、更有条理。

此目录可能还包含数据和其他“资源”，这些资源可能会被偶尔获取、存储和更新；并且可能在 Web 应用程序的某些部分使用之前进行一些处理。好吧，我想——你明白我的意思了。

那么我们的页面和所有反应组件怎么样？

那么，有趣的部分来了。至少我是这么认为的。这个方案源于一些关于 React 应用架构以及其他 Web 应用的解决方案，以及我自己的一些实践经验。到目前为止，我对它非常满意！🤓

首先，假设我们的 Web 应用程序包含一个主页、一个用户资料页，以及一个（为了避免示例中只有两个页面），我们称之为“其他页面”的第三个页面。因此，目录结构如下所示：

-- src
----- components
----- config
----- pages
--------- home
----------- index.js
----------- index.scss    // Mandatory sass file (wanted to make this look realistic!!)
--------- profile
----------- index.js
--------- other-page
----------- components
----------- index.js
----- resources

注意到所有页面都有各自独立的目录和入口点吗？“其他”页面又怎么会有一个组件文件夹呢？为什么我们需要另一个组件文件夹？根目录下不是已经有组件文件夹了吗src？

等一下！我很快解释一下！☝️

这就是我所说的“分支”结构。每个页面都有自己的目录、自己的组件集（这些组件除了在特定页面中不会在其他任何地方使用）、自己的样式规则以及其他仅与该页面相关的内容。如果两个页面共享一个组件，猜猜它们会去哪里？是的，你猜对了——components我们目录的根目录src！

但是.. 你可能会想.. 这样做的意义何在？

假设有一天，你和你的队友决定删除“其他”页面——也许是因为名字不够好？ ——你会怎么做？花一整个下午甚至一天的时间来删除代码、破坏和修复应用程序？不行。

你只需删除该目录，并移除它在 Web 应用程序中被附加/使用的位置的引用即可。瞧，大功告成！ 💁🏻‍♂️

删除一堆代码不会影响你的应用！所有代码都彼此独立，即使它们曾经绑定在一起！是不是省去了很多工作和担忧？没错，这个原则几乎可以应用于任何应用程序/软件，而不仅仅是 React 应用程序。

你们有些人可能会想——哦，不对，我们的应用程序/软件相当复杂，而且彼此之间联系过于紧密。它们共享代码，通过桥接连接在一起等等。但我想，如果你尝试运用这个原则，你现在应该明白该如何处理“共享代码”和“桥接”了！这只是一个简单的例子，用来演示并让你了解如何组织产品的各个部分，以方便使用和维护。

一个小技巧——这是我在使用 GatsbyJS 开发渐进式 Web 应用程序时学到的

您还可以继续将另一个目录添加到src-- 名为layouts（或将其添加到components目录中，无论哪个对您来说更合适）的目录中，其中包含应用程序全局的布局文件，甚至可以有多个布局；每个布局都与应用程序的某些部分相关联。例如，假设我们的应用程序还有一个漂亮的导航栏和一个不错的页脚，它们会出现在我们所有的页面中。与其将它们塞进我们的components目录中，然后在每个页面中重复使用，不如创建一个布局文件，其中包含导航栏和页脚，并渲染传递children给它的布局文件，如下所示：

<Layout>
  <div>
    Yayy! This is my fancy home page!!
  </div>
</Layout>

// And in the profile page :

<Layout>
  <div>
    This is the page of the user whose data we're secretly trying to steal! 
    Please read our privacy policies (not so) carefully!!
  </div>
</Layout>

在我们的布局文件中，我们可以有类似这样的内容：

const Layout = ({ children }) => (
  <>
    <Navbar />
    {children}
    <Footer />
  </>
);

export default Layout;

这使得你的代码更有条理、逻辑更抽象。此外，它还有助于保持页面的一致性。

但是等等... 构建 React 应用程序还有更多内容！！

是的，我没有忘记 Reducer、冗长的 Sagas、服务、大量的 Action Creator 等等！不过，这些内容都写在了本文的第二部分，因为我不想让它变得太长，读起来太累。另外，对于 React 初学者或其他刚接触 React 的开发者来说，第一部分或许可以作为一个很好的起点。

感谢阅读！欢迎在下方讨论区留言，告诉我你对这篇文章的看法。😄

您也可以通过Twitter与我联系。

祝你黑客愉快！干杯！🎉