我知道关于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/
答案 0 :(得分:1)
<强> TL; DR 强> 构建应用程序代码没有标准或正确的方法;这主要是关于你的口味。
由于我对React和Redux的经验,我会给你一个答案。现在,我参与了一个使用R&amp; R堆栈的大型项目。我们的技术团队花了很多时间讨论文件夹结构,因为我们应该保持线性和可扩展的编码方式。
基本上,我们使用混合方法混合您提供的两个示例。第二种方法被称为“按功能分类的文件夹结构”,第一种方法称为“按类型的文件夹结构”。
由于React / Redux堆栈使用标准化的文件排版,因此很容易使应用程序树尽可能保持整洁和可扩展。
我们的技术团队同意:
pages
文件夹下突出显示。 component.js
入口点,也可以使用reducer shared
文件夹下以下是我们文件结构的示意图:
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,上面提到了一些很棒的观点。
答案 1 :(得分:1)