await或者异步回调用多了，得加isValid判断好烦，生怕那个地方忘记加了，后期出bug，搞得整个人都提心掉胆的，有啥解决办法？
1赞
不要用或者少用
封装一下，回调由生命周期管控，回调的时候统一判断。
可以用generator迭代器封装一个类似unity的协程代替await
也可以用rxjs这类工具代替异步
用await的话就模仿c#的task封装一个promise，做一个类似cancelToken的东西用于取消
没懂为啥用了异步调用就得判断isValid, 你的异步调用是用在什么地方的
1赞
看着这种病毒传播式语法好揪心
你是没写过在线实时加载资源的项目吧？不是所有项目都是走个读条界面的。
望大佬给个代码片段或demo
和你用的差不多，但是总担心那块漏写了isvalid，成为一个隐藏bug
病毒式语法？你根本就不会用，还病毒式。
你要哪个解决方案的代码片段，
大概率是你不会用，多个异步条件就上 Promise.all 啊
你是NPD吧，不讨论问题本身，上来直接质疑对方的水平，显得你很厉害？
本来我觉得不了解你的项目情况不好做评价，所以才这么问的。既然你直接质疑我的经验水平，那我就把我一开始不好意思说的话直说了：
会造成你说的这种情况大概率是你项目架构/加载逻辑没有设计好，说白了就是你水平太菜。如果架构设计的好不会出现这种弱智问题。
1赞
不熟练就慢慢练呗，比如套回调地狱和promise then这类写法，await的写法更加容易维护和看懂
2赞
异步一般都这样吧
回调也得判断 isValid，异步也得判断，抨击 await 的都是连回调都不知道加 isValid 的人
哈哈. await已经是避免回调地狱的目前最可维护的一种写法了. 虽然有传染性,但是不要滥用就行.
我一般只在资源统一加载等待/.资源动态加载/网络请求回调等特别需要异步等待的情况下使用.
是否滥用取决于使用者是否理解了这个任务是否需要等待，我现在项目每个界面都用了很多，因为要请求网络数据然后展示，这是必须的等待任务
还有例如等待特效播放完成、等待事件触发。多的是，可以说必要的等待任务非常多
我有个前同事很好的解决了这个问题，不用判断isValid