ReactJS Flux 应用程序目录结构答案

【问题标题】：ReactJS Flux Application directory structureReactJS Flux 应用程序目录结构
【发布时间】：2015-07-08 19:51:21
【问题描述】：

我的团队目前正在开发一个使用 Facebook 的 Flux 架构用 ReactJS 编写的大型应用程序。它现在仍处于起步阶段，但很快就会变得很大。它将有 50 多个小组件视图、大量动作、商店和动作创建者。

目前，我们的目录结构看起来像 -

App
|___ module_1
|    |___ components
|    |    |___ component1.react.js
|    |    |___ component2.react.js
|    |___ module1ActionCreators.js
|    |___ module1Constants.js
|    |___ module1store.js
|
|___ module_2
     |___ ... (same structure as above)

这种方法的一个问题是 module_x 文件夹的数量会随着应用程序的增长而变得越来越大。

关于他们如何构建应用程序，有人有什么要分享的吗？根据我们的经验，Facebook 的示例应用程序（待办事项和聊天）具有适合小型应用程序的架构，但是一旦这些商店、组件和操作的数量增加，管理起来就会变得更加困难。

提前致谢。

【问题讨论】：

如果一个组件足够通用且足够可重用，那么将其分解为自己的 npm 模块。如果您大方，请将其开源并在react-components.com 上列出
我认为这是大型应用程序的必经之路。但是你的模块可能太小了。我的应用程序目前按类型排序，如@fisherwebdev 的答案和每个通量示例所示，但我相信这并不能很好地扩展。我已经在 store 文件夹中有 25 家商店。我打算“按功能排序”而不是“按类型排序”，这些功能中的每一个实际上都是一个小的“应用程序”，它将插入“核心”应用程序。这些中的每一个都应该只依赖于“核心”模块。这只是一个想法。尚未设计。
@RoryKoehein 您是否设计了一些尚未尝试的东西？我认为这是正确的方法。我们就是这样做的，除了我们还在功能内再次按类型排序，导致大量额外文件夹加载，其中只有几个文件。
@froginvasion 是的，我们上个月终于做到了。我们将整个应用程序移动到一个“核心”文件夹中，现在正在将模块一个一个地移出。我们还在模块内按类型排序，我同意这感觉有点多。每个模块有 1 到 5 个商店 atm。可以通过将模块从应用程序入口点中删除它们来将它们排除在应用程序之外，在那里它们被导入和加载。它们只依赖于核心。当核心或其他模块需要使用模块中的代码时，他们必须通过外观检查模块是否可用（模块也在 React 视图中的 context 上共享）。

标签： reactjs directory-structure reactjs-flux

【解决方案1】：

我还为决定大型应用程序的初始结构而苦恼。在花时间使用根据通量角色（即动作、存储、常量等）将应用程序划分为文件夹之后，我最终得到了与您的结构非常相似的结构。

首先，如果您使用的是 Broswerify 之类的工具，那么您的 require 调用上的相对路径非常好。其次，在处理特定组件时不必在各种文件夹中查找文件可以节省大量时间。

对于横切关注点，例如调度程序、辅助函数、引导程序等，我有一个等效的 App 模块。总感觉我正在使用的每个文件都有一个合理的位置，并且新开发人员不会费力地找到相关文件（当您的模块可能共享前缀时会出现问题）。

自从换了我就没有回头。

【讨论】：

【解决方案2】：

通常的目录结构是这样的：

js ├── AppBootstrap.js ├── AppConstants.js ├── AppDispatcher.js ├── 动作 │ ├── AppActions.js │ ├── FriendActions.js │ └── PhotoActions.js ├── 组件 │ ├── AppRoot.react.js │ ├── 朋友 │ │ ├── Friend.react.js │ │ ├── FriendList.react.js │ │ └── FriendSection.react.js // 一个查询视图，又名控制器视图 │ └── 照片 │ ├── Photo.react.js │ ├── PhotoCategoryCard.react.js │ ├── PhotoCategoryCardTitle.react.js │ ├── PhotoGrid.react.js │ └── PhotoSection.react.js // 另一个查询视图 ├── 店铺 │ ├── FriendStore.js │ ├── PhotoStore.js │ └── __tests__ │ ├── FriendStore-test.js │ └── PhotoStore-test.js └── 实用工具 ├── AppWebAPIUtils.js ├── FooUtils.js └── __tests__ ├── AppWebAPIUtils-test.js └── FooUtils-test.js

css 目录通常看起来像 components 目录的镜像，每个组件有一个 css 文件。然而，如今有些人更喜欢在组件上内联所有样式。

不要想太多——商店和查询视图或“部分”之间总是不是 1:1，就像本例中那样。

实际上，您只需要为您的应用做正确的事情。这不是教条。数据流的东西、控制的反转和存储的解耦——这些比你如何组织文件更重要。

【讨论】：

确实，其他的东西比文件夹结构更重要。另一方面，文件夹结构可以让您（或未来的开发人员）很好地了解正在发生的事情。我几乎认为文件夹/子文件夹/文件模型是不够的，也许提供更多灵活性的 IDE 会很有用（例如，文件夹图而不是文件夹树）。
也在这里担保：andrewcallahan.com/towards-a-simpler-react-folder-structure
所以等等......每当你使用一个动作，你必须导入"../../someActions"？如果您需要任何实用程序，也一样，您必须向上走几个文件夹。当然，它已经比我的文件夹结构更扁平了。