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

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

我通常更喜欢隔离容器，组件，actionCreators，服务和reducer的结构。无论您遵循哪种模式，一旦您的代码库扩展，您就可以使其越来越精细。我希望你熟悉Presentational与Container组件的想法。

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

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

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

简而言之，从您想要的任何结构开始简单，您最终将使用它和用例更精细和更精细。

为什么项目文件在React中组织起来？

1 个答案: