React Flux调度程序与Node.js EventEmitter - 可扩展？

Question

使用Node的EventEmitter时,您订阅了一个事件.您的回调仅在该特定事件被触发时执行:

eventBus.on('some-event', function(data){
   // data is specific to 'some-event'
});

在Flux中,您使用调度程序注册商店,然后在调度每个事件时调用您的商店.商店的工作是过滤它获得的每个事件,并确定事件对于商店是否重要:

eventBus.register(function(data){
   switch(data.type){
      case 'some-event':
            // now data is specific to 'some-event'
         break;
   }
});

在此视频中,演示者说:

"商店订阅行动.实际上,所有商店都接收所有行动,这就是保持其可扩展性的因素."

题

为什么以及如何将每个操作发送到每个商店[可能]比仅向特定商店发送操作更具可扩展性？

Answer 1

这里提到的可扩展性更多是关于扩展代码库而不是根据软件的速度进行扩展.流量系统中的数据很容易跟踪,因为每个商店都注册了每个操作,并且操作定义了系统中可能发生的每个应用程序范围的事件.每个商店都可以确定如何更新自身以响应每个操作,而程序员无需决定将哪些商店连接到哪些操作,并且在大多数情况下,您可以更改或读取商店的代码而无需担心关于它如何影响任何其他商店.

在某些时候程序员需要注册商店.该商店非常特定于它将从活动中收到的数据.如何更好地查找商店内的数据而不是注册特定事件,并让商店始终期望它需要/关心的数据？

系统中的操作表示系统中可能发生的事情以及该事件的相关数据.例如:

• 用户已登录; 附带用户个人资料
• 用户添加了评论; 附带评论数据,添加的项目ID
• 用户更新了帖子; 附带帖子数据

因此,您可以将操作视为商店可以了解的事物数据库.每次调度操作时,都会将其发送到每个商店.因此,在任何给定时间,您只需要一次考虑单个商店+操作的数据突变.

例如,当帖子更新时,您可能会看到PostStore该POST_UPDATED操作,并且当它看到它时,它将更新其内部状态以存储新帖子.这与可能也关心POST_UPDATED事件的任何其他商店完全分开 - 来自任何其他在应用程序上工作的团队的任何其他程序员可以单独做出该决定,并知道他们能够挂钩到操作数据库中的任何操作可能会发生.

另一个在代码库方面有用且可扩展的原因是控制反转; 每个商店决定它关心的行动以及如何回应每个行动; 所有数据逻辑都集中在该商店中.这与MVC这样的模式形成对比,其中控制器被明确地设置为在模型上调用变异方法,并且一个或多个其他控制器也可以在相同模型上同时(或不同时间)调用变异方法; 数据更新逻辑通过系统传播,理解数据流需要了解模型可能更新的每个位置.

最后,要记住的另一件事是注册与不注册是一种语义问题; 抽象商店收到所有行动这一事实是微不足道的.例如,在Fluxxor中,商店有一个被调用的方法bindActions,它将特定操作绑定到特定的回调:

this.bindActions(
  "FIRST_ACTION_TYPE", this.handleFirstActionType,
  "OTHER_ACTION_TYPE", this.handleOtherActionType
);

即使商店收到所有操作,它也会在内部地图中查找操作类型并在商店中调用相应的回调.