关于项目结构的问题
学着学着我就会有一些疑问，
1.老师请问一下在真实项目中这种项目结构可行吗，
把所有reducer写在一个文件夹中，
2.还有个问题老师为什么要使用多页面应用为什么不用单页面应用呢
3.为什么老师的action还会写一些逻辑把getState取出来的 当action 返回的是函数的时候，不是用在异步中吗，为什么老师要在不是异步的地方使用dispatch
正在回答
1回答
同学你好，
关于问题1，如果你指的是reducer的目录问题，我可以说这没有什么问题，在真实的项目中，reducer就是维护在一个目录下的。当然，由于我们的实战课程中，每个页面所使用的reducer函数有限，所以就写在了一个js文件中。一旦项目规模变大，这个js文件会膨胀，这种情况建议把reducer拆开成多个文件，但最终还是要合到一起交给 createStore;
关于目录的维护，唯一可能值得优化的是，对于同一个组件，可能把jsx和css放到独立的目录中比较好一些。
关于问题2，多页面和单页面显然都能达成我们的业务目标。但是，我们有四个页面的逻辑，如果都放到一个spa的话，那么其涉及的 state、ActionType、reducer会非常多且杂，不利于“关注点分离”的软件维护原则，可能造成难以维护，故障诊断困难等问题。
而且，过多冗余的js文件会增加下载时长和失败率，你可以这样理解，我们本来就想查一下车次不想买票，但是仍然下载了后面两个页面的代码，这合理吗？
SPA不是万能的，一旦系统复杂起来，该拆解就要拆解，对于降低风险十分有效。
关于问题3，你提的非常好，这个逻辑确实不是异步的，但是对于最原始的Action-Reducer模型来说，我们没有办法基于当前值来计算新值，只能赋值新值。当然，除非你手动调用 store.getState，不过这会存在循环依赖，且不够内聚，毕竟store.getState属于一种全局变量。
thunk 函数给我提供的实际上是一种callback的方式来执行Action，在支持异步的同时，顺带把 getState 也取出来了，从而支持我们获取当前值。
这确实不是异步的，但是callback的方式造成了一种异步的假象。
如果没有完全解答你的问题，请追问，祝您学习愉快！
