UI Router状态快速切换时的竞态条件问题咨询

我太懂这个坑了！之前在做复杂单页应用的时候也碰到过一模一样的问题——状态快速切换时的异步编译竞态条件真的很让人头疼。

咱们把这个场景拆得更清楚点：

• 当切换到状态A时，该状态绑定的指令会启动编译流程，其中有些嵌套指令依赖templateURL来异步加载并编译模板，这个过程本身就有网络或解析的延迟
• 要是在这些异步编译任务完成前，又快速切到了状态B，状态A对应的ui-view会被销毁，但那些还在后台跑的嵌套指令编译任务并不知道自己的“宿主”已经没了，还继续执行DOM操作，自然就会抛出异常（比如找不到挂载节点、操作已销毁的元素之类的）

针对这类问题，我总结了几个实用的解决思路：

• 给异步任务加“终止开关”：在状态的onExit钩子（或者ui-view的销毁回调）里，手动取消当前状态下所有未完成的模板加载请求；同时给嵌套指令的编译逻辑加一个标记，当宿主元素被销毁时，把这个标记设为false，后续编译步骤检测到标记就直接跳过
• 给状态导航加防抖：如果业务场景允许，给状态切换的动作加个100-200ms的防抖，避免用户在极短时间内连续触发状态切换，从源头降低竞态条件的触发概率
• 预加载高频状态模板：对于那些用户经常切换的状态，在应用初始化阶段就提前预加载它们的templateURL资源，这样切换时模板已经在本地了，不用异步编译，直接从根本上消除异步带来的竞态问题
• 指令内部做宿主存活检测：在嵌套指令的编译逻辑中，每次执行关键的DOM操作前，先检查宿主元素是否还存在于DOM树中，如果已经被销毁就立即终止后续流程

其实这类问题的核心就是异步任务没有和宿主的生命周期绑定，只要让异步操作能感知到宿主的销毁状态，及时终止无效的后续操作，就能解决大部分问题

内容的提问来源于stack exchange，提问作者Darren