首先题主要区分两个概念:React 本身和 React 生态圈所推崇的主流应用架构。React 本身其实还算简单的。最简单的理解,一个组件的渲染函数就是一个基于 state 和 props 的纯函数,state 是自己的,props 是外面来的,任何东西变了就重新渲染一遍,是不是很简单?但是,如果抛开 React 生态圈现在所有的那些东西,只用 React 本身来做个大型应用,你 hold 得住么?我可以打包票,99% 的开发者 hold 不住。因为大型应用会带来很多规模上的复杂度,比如跨组件通信,多组件共享状态,多人协作的可维护性,大量嵌套组件的性能问题... 等等。这些东西如何处理,都是靠前人填坑才一步步产生了今天的各种设计模式。Flux/Redux 的繁琐,本质上是针对大型应用的复杂度所作出的权衡:用繁琐一些的 API,换长线的可维护性。在规模不够大的应用里,这些问题并不那么明显,那么这些繁琐的 API 也就显得有些过度设计了。Dan Abramov 自己在推上多次强调过,Redux 的设计是以几个原则为优先的:要让状态的变化可追踪,可重复,可维护。为了达成这个目的,才会有 reducer, action, action creator, middleware 这些概念。本来一个 callApi(res => a.b = res) 可以做到的事情,现在你需要先写全套然后
...
继续阅读
(28)