Tim*_*eph 4 javascript state reactjs reactjs-flux
所以我最近玩React和Flux架构.
假设存在2个存储A和B.A对B具有依赖性,因为它需要来自B的某个值.因此,每当调度程序调度一个动作时,首先执行B.MethodOfB,然后执行A.MethodOfA.
我想知道这个体系结构的优点是什么优于注册A作为B的监听器,并且每次B发出更改事件时只执行A.MethodOfA？
顺便说一句:想想没有来自facebook的示例调度员的"切换案例"的Flux实现!
解决方法的问题在于,您无法保证哪些处理程序将首先处理给定事件.因此,在一个非常大的,复杂的应用程序中,这可能会变成一个纠结的网络,你不确定在什么时候发生了什么,这使得商店之间的依赖管理变得非常困难.
基于回调的调度程序的好处是双重的:存储更新自身的顺序在需要此排序的存储中声明,并且还保证完全按预期工作.这是Flux的主要目的之一 - 使应用程序的状态可预测,一致且稳定.
在一个非常小的应用程序,保证不会随着时间的推移而增长或变化,我不能与你的建议争论.但小应用程序最终会逐渐成长为大型应用程序.这经常发生在任何人意识到它发生之前.
当然还有其他的Flux方法.已经创建了相当多的不同实现,并且它们具有针对该问题的不同方法.但是,我不确定这些实验中哪些可以很好地扩展.另一方面,Facebook的Flux回购中的调度员和文档中描述的方法已经扩展到真正巨大的应用程序,并且经过了严峻的考验.
| 归档时间： |
|
| 查看次数： |
2962 次 |
| 最近记录： |