为什么项目文件会像在React中一样组织？

Question

我注意到反应项目通常是这样组织的，

/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

没有一种真正的方法来组织文件和目录，它随意见而变化。 但是人们仍然想知道组织代码的最佳方法是什么。

我通常更喜欢将容器，组件，actionCreator，服务和reducer分开的结构。 无论您采用哪种模式，一旦代码库扩展，就可以使其越来越细化。 我希望您熟悉Presentational vs. Container组件的概念。

在第一种模式中， components/只是持有仅需道具的哑巴无状态组件。 这种模式很好地支持了可重用性的概念。 当您开发大型应用程序时，通常会需要创建一个组件，您肯定知道不会在其他任何地方重用，但是您需要它。

容器/具有进行API调用的有状态组件。 同样，如果您在应用程序中使用redux，许多人会尝试遵循ducks模式，在该模式中，您将所有的reducer以及您的root reducer一起定义在一个目录中，只是为了使事情更细化和易于访问，而您却没有这样做。不必在文件之间跳转即可创建动作。

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

简而言之，从您想要的任何结构开始简单，最终将使您的用例和规模变得越来越精细。