This topic created in 3865 days ago, the information mentioned may be changed or developed.
现在认同度较高的 react 最佳实践是这样的：
把 app 拆成一堆 dumb components 。这些 dumb components 只负责把从 props 传递过来的数据显示出来。它们注册例如 click 这样的事件，但是如何响应这些事件也是由 props 传递过来的函数决定。
跟这个 app 相关的所有 state 都保存在最高一级的 component 里。处理 state 的所有逻辑也都在这里。这个 component 只是把所有的子 components 套在一个 div 里。可以看做是只负责逻辑，跟 view 无关。
在上面描述的 pattern 里，最高一级的 component 就是 mv* 里的 model(view model)。 dumb components 只是一堆模板，可以看做 view 。通过 props 传递数据的方式跟传统的变量绑定也没什么不一样。
Supplement 1 · Sep 29, 2015
大家都说 react 属于 view 层，应该拿 flux 去跟 mv* 比较。但是只要你是写 react ，只要你的 react 不止一个子 component 。那你就必须按照某种 pattern 来写。而我想说的就是现在推崇的 smart component + dumb component 的 pattern 跟 mv* 没什么不一样。
如果大家尝试过各类 flux 实现，特别是 redux ，就应该能感受到 flux 就只是最上面的那级 smart component 而已。
最早的 react 提倡 component 的 self encapsulated ，于是他们把模板和逻辑用 jsx 的方式写在一起。接下来 flux 出现，各类最佳实践又提倡应该把逻辑统一到一个地方处理， components 只做渲染数据。大家不觉得 react 实际上是在走回头路么。
如果大家尝试过各类 flux 实现，特别是 redux ，就应该能感受到 flux 就只是最上面的那级 smart component 而已。
最早的 react 提倡 component 的 self encapsulated ，于是他们把模板和逻辑用 jsx 的方式写在一起。接下来 flux 出现，各类最佳实践又提倡应该把逻辑统一到一个地方处理， components 只做渲染数据。大家不觉得 react 实际上是在走回头路么。
5 replies • 2015-09-29 16:47:46 +08:00
 |
1
YuJianrong Sep 29, 2015
这个描述很正确，基于这个原因我也觉得 react 并不适用于需要复杂交互的场景（还不如用 MVVM ）。
不过阁下说 MV*过时就无法苟同了。 MV*是为了 model 和 view 的分离而出现的，这无论在何时都是重要的 practice ，可能以后 MV*会有一些更新的方法和演化，但我不觉得这个理念会过时掉…… |
 |
2
joyee Sep 29, 2015
比较对象不是一个次元的啊，宣称要搞掉 MV* 的是 flux ， react 只是一个 view 层的库……
|
 |
3
ChefIsAwesome OP @YuJianrong react / flux 他们说 mv* 过时。
@joyee flux 就是个大的 react component 。 react 自己的文档里，谈到 prop 和 state 如何使用时就说，尽量写 stateless 的 components ，这已经涉及到设计模式层面了。 |
|
4
joyee Sep 29, 2015
@ChefIsAwesome 然而 flux 和 react 之间没有必然的依赖关系…… flux 可以搭配别的 view library ， react 也可以搭配别的 MV* framework ……
|
 |
5
otakustay Sep 29, 2015
首先， react 是 View 层解决方案，不应和 MV*做比较
flux 在不与 react 一起玩的时候，是可以和 MV*做比较的，本身是一个 application 级的模式 我认同 flux 和过时 MV*并没有区别，顶多是过时的 MV*很多人没玩好，所以 flux 来重新定义一下各个细节，给予更大的限制不让你犯错 |
Select Language