构建可扩展的前端项目

和其他 Web 开发者和工程师一样，我更倾向于让自己的工作生活尽可能理智。拥有清晰的架构不仅能让生活更愉快，而且对扩展至关重要，甚至能让创造力蓬勃发展！清晰的代码结构和一致的规划能让我保持高性能，更好地规划扩展，避免不必要的代码重构，并理解应用程序的层次结构，而无需在每次需要更改或升级功能时重新学习每个组件或服务。

几乎所有刚开始使用 JavaScript 框架的开发者都会使用其他团队为该框架构建的内置 CLI（命令行界面），以便以最小的投入快速启动开发流程。这种方法本身并没有什么问题，而且可以让开发者在遇到第一波配置错误时节省大量时间。设置完成后，下一步就是构建代码结构。毫无疑问，每个人对此都有自己的看法，并且会坚决维护自己的方法。我也在不断完善自己的架构，以适应项目的发展。

在本文中，我们将使用 create-react-app 启动结构作为基础配置，任何人都可以在遵循本文的同时开始使用它，而不会迷失方向。

这是什么，不是什么

本文将深入探讨项目结构和软件包的见解。本文并非全面探讨哪些库和软件包应该使用，哪些应该避免，以及哪些库和软件包应该“必须”和“不能”。你的项目是一个动态的结构！我的观点和意见适用于你所面临的问题，但根据最终用户或开发团队的需求，这些问题可能适用也可能不适用。希望本文能为你和团队在处理小型和大型项目时保持井然有序提供另一个有价值的视角。

基本配置

因此您不必挖掘链接和网站，这里是create-react-app您开始时将看到的文档结构。

my-app
├── node_modules
├── public
│   ├── favicon.ico
│   ├── index.html
│   ├── manifest.json
│   └── robots.txt
├── src
│   ├── App.css
│   ├── App.js
│   ├── App.test.js
│   ├── index.css
│   ├── index.js
│   ├── logo.svg
│   ├── serviceWorker.js
│   └── setupTests.js
├── .gitignore
├── package.json
├── README.md
└── yarn.lock

我对 src 和 components 文件夹有相当强烈的意见。不要把所有东西都用 src 或 components 文件夹！这对于大型应用程序来说不可扩展，而且当你想查找特定代码时，翻遍一大堆扁平的 .js 文件列表非常烦人。

大写与小写

让我们快速解决这个问题。React 开发者喜欢根据该领域一些知名开发者的约定，将组件相关的文件定义为大写。如果你参与的其他人的项目也使用大写字母，请不要更改所有文件名。标准已经设定，修改单个项目的标准有其正确和错误的时间。

另一方面，如果你要在我的项目上工作，小写文件名是我们的准则。它简洁易读，而且几乎所有其他类型的项目和框架都使用这种方法。此外，单词之间必须使用连字符，即使这会使文件名略长，超出你通常阅读的舒适范围。

Google 的文件命名标准

新的前端架构

如果您只是想为本文寻找一个示例，了解如何构建您的下一个项目，我会在这里为您提供一个简化版本的链接。如果您想继续阅读，了解为什么采用这种结构，并理解这种架构的目的，请继续阅读。我们将采用MVVM架构来管理我们的项目。

您的大多数项目初期可能都是 100% 基于前端的，使用内部或外部 API，或者使用与前端代码绑定不紧密的独立数据源。例如，如果我们在构建项目时考虑了服务器端渲染，我们的架构可能会发生变化。让我们来大致了解一下新应用文件夹中的内容。

my-app
├── assets
│   ├── images
│   ├── scripts
│   └── styles
└── src
    ├── components
    ├── constants
    ├── models
    ├── routes
    ├── services
    ├── views
    ├── utilities
    ├── index.css
    ├── index.js
    └── serviceWorker.js

index.js

在提供的示例中，index.js 被大量用于导出多个组件或表示视图或共享元素的父组件（容器）。

资产

让我们稍微分解一下资产并了解发生了什么：

assets
├── images
├── scripts
    └── vendors
└── styles
    └── vendors

src 文件夹中的 assets 文件夹通常位于此处，用于存放仅供内部使用的资源，这些资源不应以独立、可链接或可下载的形式向公众开放。PDF、下载内容、博客文章图片等……可以存储在 public 文件夹中，以便进行大规模分发。

我不会推荐为图片设置特定的子结构。我甚至没有一个明确的观点，除了可能将图片按页面、功能、布局和特定用例分组。脚本通常是第三方库，无法自然集成（导入/依赖）到你的项目中，你可以将它们放在 HTML 文档正文的开头或结尾。styles 文件夹也是如此。

之所以设置 vendor 文件夹，是因为这样更容易处理位于基础文件夹内的 scripts 和 styles 文件夹中的内部编写文件，而外部/第三方库则位于 vendor 文件夹中。这样团队成员可以更轻松地进行直观的参考，甚至可以添加相关的覆盖（如果您由于未来可能的更新而无法修改主库文件），例如 bootstrap.min.css 和 bootstrap-overrides.min.css。虽然对某些人来说可能不太理想……但它井然有序，易于参考。请记住，脚本和样式主要用于第三方库，这些库不会存在于您主项目的 JavaScript 文档和样式表中。

成分

我们将保留组件文件夹，因为我仍然认为它很重要。它的用途不应该是保存你的项目，而应该保存将在整个项目中共享的组件。这些组件包括：布局、私有组件、公共组件、模板、侧边栏、标题等等……任何你想要的、将被多个模块或视图多次使用的组件。

components
├── buttons
├── forms
├── layouts
├── partials
├── private
│   ├── header
│   ├── sidebar
│   ├── card
│   └── modal
├── public
│   ├── header
│   ├── pricing-tables
│   └── footer
└── shared

请注意，我喜欢将那些仅用于面向客户的网站或面向用户的应用的组件分为公共组件和私有组件。它们也可以分别命名为网站和应用，或者您可以将所有组件文件夹放在组件下的同一层级。重要的是为项目中的可复用组件提供一个主目录或主要位置。至于多个文件夹名称，由于组件命名的用例千差万别，我目前仍未做出决定。

模型和服务

让我们将它们捆绑在一起。以 MVVM 方法为灵感，模型将包含构造函数，用于将传入和传出的服务器数据塑造成可重复且可扩展的对象。服务将包含通用函数和专用函数，用于在客户端和服务器之间来回发送这些数据。服务还将包含基于状态的解决方案，例如 Redux 配置或全局上下文。

├── models
│   ├── client.js
│   ├── product.js
│   └── task.js
└── services
    ├── context
    ├── redux
    └── api
        ├── clients.js
        ├── products.js
        └── tasks.js

常量

应用程序中全局引用的所有内容都应存储在此处。这些内容包括：

1. 来自数据库的唯一 ID（id 或 guid）。
2. 不属于 .env 文件一部分的差异 api 服务的配置值。

请注意，如果根据您的托管配置方式或公司政策的执行方式，该文件夹被视为动态的，则可以将其替换为保存所有信息的 .env 文件。

实用工具

实用程序可以是一个或多个文件，用于定义应用将使用的小型实用函数。这些函数可以是专用日期、格式化程序，或者一些经常需要但不属于项目中任何组件或模块的一次性函数。

路线和视图

很可能，你一天中的大部分时间都花在这里和组件之间，整理设计师交给你的最终代码以供实现。你已经编写了模型和服务来使用来自服务器的数据，现在你需要利用这些数据。一个基本的视图结构可能如下例所示。

对我来说，将路由放入单独的文件夹是一件比较新鲜的事情。将路由放在一起并导入路由的视图，让我能够更轻松地管理我最近的应用程序随着业务需求的变化而变化。这更多的是个人偏好，而不是强制要求别人使用的模式。

routes
├── components
│   ├── private.js
│   ├── public.js
│   └── index.js
├── index.js
views
├── private
│   ├── clients
│   ├── dashboard
│   ├── products
│   ├── tasks
│   └── index.js
├── public
│   ├── about
│   ├── auth
│   ├── home
│   └── index.js
└── shared

再次强调，我喜欢通过将面向公众的网站和面向客户的内部应用进行分离，来直观地理解我的项目结构。每个视图组件文件夹都是定义路由视图的地方。

client
├── index.js
├── client-redux.js
├── client.scss
├── client-styles.js
├── tests
├── components
│   ├── modal 
│   └── // unique components for view
clients
├── clients-redux.js
├── clients.scss
├── clients-styles.js
├── index.js
├── tests
└── components
    ├── modal
    ├── list-item
    |   ├── list-item.scss
    |   ├── list-item-styles.js
    |   └── index.js
    └── // unique components for view

此示例包含您在项目中使用的一系列文件。我们还将那些不宜放在共享组件文件夹中的特有子组件分离到视图中，并将它们保留在视图的组件文件夹中。通过采用包含几乎所有与视图相关的内容的“重度视图”方法，我们可以在新旧代码的实现和弃用过程中进行维护。这使得我们的开发周期更加精简和敏捷。由于不同的开发人员负责不同的功能，我们还可以避免开发人员代码和拉取请求的重叠。

结论

至此，我们定义了一个更具可扩展性和可维护性的架构的总体框架。在某种程度上，该架构与您的前端库无关，并且可以根据您团队的需求进行修改。由于项目是动态变化的有机体，我也会犯错，所以如果我遗漏了任何内容，请告诉我。您最喜欢或更倾向于哪种前端结构方法？请在下面的评论区告诉我。我很乐意听到您的意见！

如果您想要此版本的入门版本，这里提供了链接：React-Starter

如果您觉得本文有帮助或有用，请分享💓、🦄或🔖。谢谢！