为了更了解其他人对软件工程的看法，我开始疯狂在 YouTube 上追 TechLead 的视频。在接下来的几天里，我为他在 Google 工作时提出的一道面试题想出了各种解决方案。...

为了防止自己手动调用 store.dispatch ，一般会使用redux的这个 bindActionCreators 方法来自动绑定 dispatch 方法，用法如下。

MVC中，数据（Model）、表现层（View）、逻辑（Controller）之间有明确的界限，但数据流是双向的，在大型应用中尤其明显。一个变化（用户输入或者内部接口调用）可能会影响应用的多处状态，例如双向数据绑定，很难维护调试...

简言之，把DnD特性拆解成一些基础interface（能抓东西，即萝卜；能放手容器，即坑），并把DnD内部状态暴露给实现了这些interface的实例。不像其它库一样提供无穷尽的Draggable Component应对常见业务场景，React DnD从相对底层的角度...

也就是说，只要知道哪些东西是状态相关的（源于应用状态），在状态发生变化时，就应该自动完成状态相关的所有事情，自动更新UI，自动缓存数据，自动通知server...

react-redux作为胶水一样的东西，似乎没有深入了解的必要，但实际上，作为数据层（redux）与UI层（react）的连接处，其实现细节对整体性能有着决定性的影响。组件树胡乱update的成本，要比多跑几遍reducer树的成本高得多，所以有必要了解...

简言之：dva想提供一个基于业界react&redux最佳实践的业务框架，以解决用裸redux全家桶作为前端数据层带来的种种问题

作为一个Redux中间件，想让Redux应用中的副作用（即依赖/影响外部环境的不纯的部分）处理起来更优雅

最核心的两个东西是createStore和applyMiddleware，地位相当于core和plugin

可以把各个f单独拎出来测试，组合起来肯定没有问题，从理论上确定了组件质量是可靠的，组合出来的整个应用的UI也是可靠的