Javascript 为什么项目文件按其所在位置进行组织？

我注意到react项目往往是这样组织的

/src
  /actions
      userActions.js
      settingsActions.js
  /components
      userComponent.js
      settingsComponent.js
  /containers
      userContainer.js
      settingsContainer.js
  /reducers
      userReducers.js
      settingsReducers.js

在类型上而不是功能上耦合

/src
  /user
      userActions.js
      userComponent.js
      userContainer.js
      userReducers.js
  /settings
      settingsActions.js
      settingsComponent.js
      settingsContainer.js
      settingsReducers.js

为什么呢？据我所知，React在某种程度上是好的，因为它将css、html和js结合在一起，而不是将它们分开。为什么不在文件结构上也这样做呢？

没有一种真正的方法来组织文件和目录，这取决于不同的意见。但人们仍然想知道组织代码的最佳方法是什么

我通常更喜欢容器、组件、ActionCreator、服务和缩减器分离的结构。无论您遵循哪种模式，一旦代码库扩大，您都可以使其变得越来越细粒度。我希望您熟悉表示组件与容器组件的概念

在第一种模式中，components/只保存只需要道具的无状态哑组件。此模式非常支持可重用性的概念。当您开发大型应用程序时，经常需要创建一个组件，您肯定知道它不会在其他地方重用，但您需要它

容器/具有进行API调用的有状态组件。同样，如果您在应用程序中使用redux，许多人会尝试遵循ducks模式，即您在一个目录中定义所有的reducer以及根reducer，只是为了使内容更细粒度，更易于访问，并且您不必在文件之间跳转来创建操作

这只是我的观点，但正如我前面提到的，它完全取决于应用程序的用例以及开发它的人的意见。另一种方法是按功能区域组织文件，如您在第二个目录结构中所述，使用类似用户和设置之类的文件夹功能。这种组织风格一开始看似简单。但不可避免的是，你最终会得到一个公用文件夹，在这个文件夹中，你会存储一些非常基本和常用的组件，比如button，这些组件在你的应用程序中随处可见。最终，你会得到通用/组件和通用/容器，但会更深一层

---

简言之，从简单的结构开始，不管你想要什么，你最终都会随着你的用例和规模而变得越来越精细。

动作、组件、容器、还原器通常是分开的，因为它们代表不同的功能，如果你把它们放在一起，可能会让人困惑。但是，您可以根据功能性在其中组织子目录。您还可以像您所提到的那样构建您的项目，在第一个代码块中将其主要基于观点的src更改为用户，并突然将其作为第二个代码块的更好组织版本。您将在教程等中看到第一个块，因为它们只有一个功能。一旦你获得了多个特性，你就可以重命名src，把它提高一个级别，你就可以开始了