角度 – Redux Vs BehaviourSubject – 有什么区别？
|
假设您是Angular开发人员,您可能拥有一项名为User Service的服务.此服务具有您的组件订阅的行为主题(请参阅rxjs),并且假设该服务还具有一些方法来更改用户状态.
您的顶级组件侦听用户服务状态并将其输入到其子组件.然后,该子组件调用服务上的方法来更改用户状态,并且行为主体发出新值.现在,您的组件侦听获取更新的值并将其传递给其子级. 或者在另一个实现中,您在同一级别拥有一堆组件来监听状态更改.一个调用服务方法来改变状态并发出状态,所有组件监听都获得新状态. 在Redux方面,我很新,但我知道有一个州区.你的组件改为写入状态并从那里听取状态. 我没看到差异？我知道Redux还允许您查看实际调用哪些操作来更改状态,而在行为主题示例中,它们完全解耦,并且没有关于状态更改的原因或方式的概念 – 他们只知道状态现在是什么. 有人可以解决一些问题吗？ 解决方法
当我遇到一个非常常见的用例时,我遇到了这个问题：开发一个可以从我的app中的任何地方切换的加载器/微调器.
我自己提出了一个类似的问题：redux的好处究竟是什么,特别是当行为主体处理我当前的需求时. 我推荐这篇文章： 文章提到了应该使用商店的关键时刻,以及一些好处： >将组件树注入到自然超出范围的组件中时. (使用actsubject避免像这样注入) 它还提到使用像Redux这样的商店的负面消息： >商店确实解决了组件交互的问题,但它也创建了在应用程序中管理状态的需求,否则在使用其他解决方案时可能不存在. 观看完所有视频,阅读所有文字后,我认为Redux很棒.我真的想用它.但是,对于我目前仅共享单个对象状态的用例： { show: true }
要么 { show: false }
当rxjs / behaviorsubject以非常小的开销完全满足我的需要时,采用整个库来处理这种单一状态显然不是正确的选择. 这篇文章真的让我印象深刻： 如果您不知道是否需要Redux,则不需要Redux. 我想也就是说,Redux在这里解决了一个巨大的问题：跨大型数据存储的数据不变性.如果你没有那个问题……你还不需要Redux. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |