我知道关于react-redux项目代码结构的问题很少,但我希望讨论一种不同的方法.所以我们要使用的主要库是:webpack – react – redux -mocha – karma.
这个经典的文件夹结构似乎是:
js
├── actions
│ ├── action-for-componentA.js
├── components
│ ├── componentA.js
├── reducers
│ ├── reducer-for-componentA.js
└── stores ...
这似乎是其他所有人和所有发电机都在做的事情.但我觉得这不是构建项目的反应方式.重点应该放在组件上,而不是放在反应或还原的各个构造上.我想以这种方式考虑它,当你需要更改PageX中的一个按钮时,该按钮包含在以ComponentX开头的组件层次结构中 – > ChildOfX – 我应该能够以完全相同的方式遍历目录.
而不是让一个组件文件夹中包含所有组件,我宁愿有类似的东西:
js
├── PageX
│ ├── action-for-pagex.js
├── componentX.js
├── containerX.js
├── reducerX.js
├── children
├── childrenC
├── childrenB
├── componentB.js
├── reducerB.js
├── ...
├── PageY
│ ├── ...
├── PAgeZ
│ ├── ...
这将更容易遍历,当你思考“反应”时更有意义.任何人都可以看到这种方法可能出错的地方吗?
相关阅读:http://engineering.kapost.com/2016/01/organizing-large-react-applications/
最佳答案 TL; DR
构建应用程序代码没有标准或正确的方法;这主要是关于你的口味.
由于我对React和Redux的经验,我会给你一个答案.现在,我参与了一个使用R& R堆栈的大型项目.我们的技术团队花了很多时间讨论文件夹结构,因为我们应该保持线性和可扩展的编码方式.
基本上,我们使用混合方法混合您提供的两个示例.第二种方法被称为“按功能的文件夹结构”,第一种方法称为“按类型的文件夹结构”.
由于React / Redux堆栈使用标准化的文件排版,因此很容易使应用程序树尽可能整洁和可扩展.
我们的技术团队同意:
>每个主要组件在页面文件夹下突出显示.
>每个页面也可能有一些子组件.
>组件使用component.js入口点,也可以使用reducer
>实际从多个父组件继承和使用的子组件放在共享文件夹下
>我们还维护一些辅助函数文件夹和一个包含一些常量和实用程序的文件夹.这主要是因为我们的操作调度程序在我们的应用程序生命周期中使用了常见操作.
>应用程序是由单个容器,单个存储和简单入口点(app.js)引导的.
>我们使用ES6 import语句来保存所有内容.
这是我们的文件结构的示意图:
constants
-- const.js
-- const2.js
helpers
--helperfunc1.js
shared
--Shared Element1
--- component.js
--- reducer.js
--Shared Element2
--- component.js
--- reducer.js
specs
-- spec1.js
-- spec2.js
pages
-Page1
-- Subpage1
--- component.js
--- reducer.js
-- Subpage2
--- component.js
--- reducer.js
-- component.js
-- reducer.js
-Page2
-- component.js
-- reducer.js
...
container.js
app.js
reducer.js
在我们不断编码,添加功能和维护我们的应用程序时,我们写下了这种方法的一些优点:
– 文件名非常简短,易于阅读.
– 文件结构易于遵循.
– 从文件夹导入组件和减速器时,测试变得非常简单
– 命名瓶颈已被丢弃.
– 我们在同一个文件夹下的命名问题较少.
– 再次,TableDataComponent.js比table / component.js更详细,更难以遵循.
– 由于React嵌套组件是框架的重要组成部分,因此文件夹结构会跟踪此逻辑.内部代码级别从上部渲染元素继承.
– 动作减速器也可以顺利地进行自举.
我建议花一些时间阅读这个精彩的Reddit thread和article,上面提到了一些很棒的观点.