javascript - 使用 React 和 Redux 的分形项目结构 - 优点/缺点

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

我想知道在 React + Redux 项目中使用分形结构的优点和缺点，我想知道是否有人有这种方法的经验，或者是否存在陷阱从文档中无法立即看到。

(Fractal structure) Also known as: Self-Contained Apps, Recursive Route Hierarchy, Providers, etc

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

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

• /events列出所有事件
• /events/new显示插入新事件的表单
• /events/1/details显示有关事件的详细信息id 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文件夹。

文档强调了这个主要优点:

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

Answer 1

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

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

所以现在看起来像:

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

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