具有React和Redux的分形项目结构 - 优点/缺点

时间:2016-06-30 18:10:25

标签: javascript reactjs architecture redux

我想知道在React + Redux项目中使用 Fractal Structure 的优缺点是什么,我想知道是否有人对此方法有任何经验或者是否存在陷阱没有立即从文档中看到。

  

(分形结构)也称为:自包含应用程序,递归路由层次结构,提供程序等

上下文: 我正在查看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
~

NewDetails文件夹嵌套在根Event文件夹下。

文档突出了这个主要优点:

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

2 个答案:

答案 0 :(得分:6)

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

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

所以现在它看起来像:

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

这不是世界末日,但是你的漂亮等级不再是严格的等级了。

答案 1 :(得分:1)

我可以说的一个缺点是无法at a glance查看所有可用的路由及其各自的组件,这可以通过提供一些描述性注释来减轻,但它确实增加了路由配置的复杂性。我还试图将嵌套文件夹保持在最小,因为在导入语句中获得嵌套级别的认知负荷是正确的,../../../../../ 如果您有许多嵌套路线,这些可能会失控。