使用 React 和 Redux 的分形项目结构 - 优点/缺点 [关闭]

Question

我想知道在 React + Redux 项目中使用 分形结构 的优缺点是什么，我想知道是否有人对这种方法有任何经验，或者是否存在哪些陷阱从文档中看不到。

（分形结构） 也称为：自包含应用程序、递归路由层次结构、提供程序等

上下文： 我正在查看react-redux-starter-kit，它建议使用fractal structure 来组织文件夹。如果我理解得很好，这种方法需要按功能组织项目文件夹并递归嵌套路由。

所以，如果我有一个“事件”资源在哪里

• /events 列出所有事件
• /events/new 显示用于插入新事件的表单
• /events/1/details 显示有关事件的详细信息 编号 1

从样板开始，我必须添加新的路由文件夹，例如：

├── src                      # Application source code
│   ├── main.js              # Application bootstrap and rendering
│   ├── components           # Reusable Presentational Components
│   ├── containers           # Reusable Container Components
│   ├── layouts              # Components that dictate major page structure
│   ├── static               # Static assets (not imported anywhere in source code)
│   ├── styles               # Application-wide styles (generally settings)
│   ├── store                # Redux-specific pieces
│   └── routes               # Main route definitions and async split points
│       ├── index.js         # Bootstrap main application routes with store
│       ├── Root.js          # Wrapper component for context-aware providers
~       ~
│       ├── Events           # Fractal route
│       │   ├── index.js     # Route definitions and async split points
│       │   ├── components   # Presentational React Components
│       │   ├── container    # Connect components to actions and store
│       │   ├── modules      # Collections of reducers/constants/actions or single DUCK module
│       │   └── routes       # Fractal sub-routes (** optional) <-------------
│       │       │
│       │       └── New
│       │       │   ├── index.js     # Route definitions and async split points
│       │       │   ├── assets       # Assets required to render components
│       │       │   ├── components   # Presentational React Components
│       │       │   ├── container    # Connect components to actions and store
│       │       │   ├── modules      # Collections of reducers/constants/actions or single DUCK module
│       │       │   └── routes       # Fractal sub-routes (** optional) <-------------
│       │       │
│       │       └── Details
│       │           ├── index.js     # Route definitions and async split points
│       │           ├── assets       # Assets required to render components
│       │           ├── components   # Presentational React Components
│       │           ├── container    # Connect components to actions and store
│       │           ├── modules      # Collections of reducers/constants/actions or single DUCK module
│       │           └── routes       # Fractal sub-routes (** optional) <-------------
~       ~
│       └── NotFound         # Capture unknown routes in component
~

New 和 Details 文件夹嵌套在根 Event 文件夹下。

文档强调了这些主要优点：

• 它比平面目录结构更好地扩展，文件夹用于 组件、容器等。
• 可以将路由捆绑到“块”中 使用 webpack 的代码拆分和合并算法
• 由于逻辑是自包含的，因此可以轻松地将路由分解为单独的 存储库并使用 webpack 的 DLL 插件引用以实现灵活， 高性能开发和可扩展性。

Answer 1

我可以说的一个缺点是无法at a glance 查看所有可用的路线及其各自的组件，这可以通过制作一些描述性的 cmets 来缓解，但它确实增加了路线配置的复杂性。我还会尝试将嵌套文件夹保持在最低限度，因为在导入语句中获得正确的嵌套级别会产生认知负担，即../../../../../ 如果您有许多嵌套路由，这些可能会失控。

Answer 2

我遇到的类似结构的一个缺点或缺点是，如果/当开始在其层次结构之外使用事物时，您必须在导入中使用大量 ../../..。

例如，假设您要求在 StartPage 路由上显示最新事件的详细信息。

所以现在看起来像：

routes
├─Events
│     ├─New
│     ├─Details
├─StartPage
       ├─ components   // here somewhere you import ../../Events/Details

这不是世界末日，但你漂亮的层次结构不再那么严格了。