javascript - 为什么项目文件按照 React 中的方式组织？

Question

我注意到 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 结合在一起，而不是将它们分开。为什么不同样使用文件结构呢？

Answer 1

没有唯一真正的方法来组织文件和目录，它因观点而异。但人们仍然想知道组织代码的最佳方法是什么。

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

在第一个模式中，components/ 仅保存仅接受 props 的无状态无状态组件。这种模式很好地支持了可重用性的概念。当您开发大型应用程序时，经常会发生这样的情况:您需要创建一个您明确知道不会在其他地方重用但又需要它的组件。

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

这只是我的观点，但正如我之前提到的，这完全取决于应用程序的用例以及开发它的人的意见。另一种方法是按您在第二个目录结构中提到的功能区域组织文件，其中包含用户和设置等功能的文件夹。这种组织风格一开始看似简单。但不可避免地，您最终会得到一个文件夹 common，其中存储非常基本和常见的组件，例如按钮，这些组件在您的应用程序中到处使用，最终您将得到 common/components > 和 common/containers，但更深层次。

简而言之，从简单的结构开始，无论您想要什么结构，最终都会根据您的用例和规模使其变得越来越精细。