以下是其中使用SwitchMap的一个示例：从购物车中删除项目
购物车列出了用户打算购买的产品，并且每种产品都有一个按钮将产品从购物车中删除。单击此按钮以将FromCart删除到相应的API与应用程序的后端通信，并检查从购物车中删除的物品。
该代码似乎能够正常运行，但实际上，SwitchMap的使用引入了竞赛条件。
如果用户单击购物车中多个项目的删除按钮，则会出现什么样的行为？
根据客户端单击按钮的速度，应用程序可能::
让我们考虑是否可以使用以下操作员替换SwitchMap。
如果SwitchMAP被Mergemap替换，则效应代码将同时处理每个调度操作。
换句话说，待处理的删除不会被暂停。返回请求将在同一时间发生。当请求完成后，与调度相对应的操作。
应该注意的是，由于操作的并发处理，响应的顺序可能与请求的顺序不匹配。例如，如果用户单击第一个和第二个项目的删除按钮，则第二项删除项目可能发生在第一个项目删除之前。
对于购物车中项目删除的场景，删除订单并不重要。因此，使用Mergemap代替SwitchMap可以修复错误并避免潜在条件。
从购物车中删除商品的顺序可能并不重要，但是某些操作通常对分类很重要。
例如，如果我们的购物车具有增加商品数量的按钮，那么以正确的顺序处理操作很重要。否则，前端购物车的数量最终可能不会与后端的数量同步购物车。
对于分类的重要操作，您应该使用ConcatMap。
ConcatMap等同于使用并发合并。也就是说，使用ConcatMap使用效果代码只会一次处理一个后端请求，并且按计划的顺序排列操作。
ConcatMap是一个安全且保守的选择。使用SwitchMap，Mergemap或ConcatMap生效时，使用Concatmap更安全。
每当计划使用相同类型的操作时，使用SwitchMap将被暂停以查看悬挂的后端请求。这使SwitchMap不安全用于创建，更新和删除操作。但是，它也可能引入读取操作的错误。特定的读取操作取决于是否在分配另一种类型的另一个操作后仍需要后端响应。LET使用switchmap查看错误的操作。如果我们的购物车中的每个产品都有一个详细的信息按钮 - 以显示一些内部链接详细信息 - 以及处理详细信息操作/epic使用SwitchMap的效果，介绍竞争条件。如果用户单击几个项目的详细信息按钮，这些项目的详细信息是否取决于用户单击的速度button.Button.ement FromCart，使用Mergemap可以修复错误。旋转图仅应在有效/史诗般的情况下使用，并且仅使用背面- 分配了同一类型的另一个操作后端响应。
让我们看一个实用的切换示例场景。
如果我们的应用程序购物车显示了产品的总成本以及货物，则每次更改购物车内容的内容，将触发GetCarttotal读取操作。
使用SwitchMap处理GetCarttotal操作的操作是完全合适的。
如果效果是在处理GetCarttotal操作时更改购物车，则对待处理请求的响应已经旧了 - 这是上一个购物车中的项目总数 - 因此，暂停阅读操作请求是合理的。
实际上，暂停此不必要的阅读请求，而不是允许读取请求完成，然后忽略 - 或更糟糕的是，接口上的旧响应更需要。
排气板可能是最不知名的扁桃操作员，但是很容易解释：可以将其视为SwitchMap的相反。
如果使用SwitchMap，则将暂停待处理的后端请求以支持最近的分销操作。
相反，如果您使用排气板，则在有挂回端请求时，将忽略操作的划分。
开发人员应该熟悉一种特殊类型的用户：倾向于重复重复相同的按钮。尤其是在不断单击按钮并且没有响应时，这些用户将再次单击它。
如果购物车具有刷新按钮并使用SwitchMap处理清爽效果代码，则每个连续按钮点击将暂停先前的触发刷新操作。
如果购物车刷新的效果图被更改为排气误，则将忽略要处理的刷新请求。
原始：https：//juejin.cn/post/7099793930216013855