【发布时间】:2019-04-19 09:20:40
【问题描述】:
使用 Redux 时,通常更好的做法是:实现 entity specific reducer 还是基于严格的 action keying 约定实现 generic reducer?以前的解决方案有很多样板代码,但松耦合且更灵活。后一种解决方案的样板更少,但更脆弱和限制性更强。
由于我们的域有几十个实体,我最初倾向于后一种解决方案。我设计了通用实体化简器,它利用 JavaScript 计算属性名称根据调度的动作类型来操纵状态。这一切都是动态的和基于约定的。
起初,该解决方案运行良好,直到我意识到在某些用例中不同实体资源之间存在结构不匹配。一些端点返回一个集合,其中一些返回一个结果等等。因此我不得不分解通用化简器以适应不同的用例。我开始在这里和那里添加条件逻辑的 sn-ps。最终发现自己迷失了方向!现在我很难让事情恢复正常。在架构上清晰的视觉实际上很快就很难维持大泥球。
我是否应该放弃通用解决方案并重构商店以使用实体特定的减速器而不考虑样板?是否有人真正成功地为复杂的 Admin GUI 应用程序实现和维护了通用减速器逻辑?
【问题讨论】:
标签: javascript reactjs rest redux state