缺少任务暂停机制支持
lispking opened this issue · 6 comments
看代码实现 ，貌似没办法支持任务暂停机制，实际上，有一些场景需要弹窗，等用户确认后才继续往后运行，取消后中断后续任务或继续运行。
初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。
初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。
拆成两块存在一些问题，用户需要在异步回调后手动调用恢复任务函数让任务继续往下运行，如果用户忘记调用该函数，会导致后续任务链陷入假死状态。
初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。
拆成两块存在一些问题，用户需要在异步回调后手动调用恢复任务函数让任务继续往下运行，如果用户忘记调用该函数，会导致后续任务链陷入假死状态。
不过依然建议的是：这种业务场景不太符合设计初衷哦。实际上不拆除也有一些方法可以做。你可以把弹窗当作某个任务中的某部分内容，只有当确认的或者取消的时候，任务才可能继续完成执行这部分内容。如果该任务在子线程，用循环卡住，如果任务在主线程，用sleep+轮训处理。 你可以参考下处理。
初始化的场景比较复杂，而且还需要考虑多个同异步混合链。初始化需要在应用应用启动的时候尽可能快才是合理的。需要用户等待确认的场景一般是用于业务逻辑，如果真的你可以在业务场景中把你需要暂停的场景，建议把依赖链拆成两块，但这不是该库设计的初衷。
拆成两块存在一些问题，用户需要在异步回调后手动调用恢复任务函数让任务继续往下运行，如果用户忘记调用该函数，会导致后续任务链陷入假死状态。
不过依然建议的是：这种业务场景不太符合设计初衷哦。实际上不拆除也有一些方法可以做。你可以把弹窗当作某个任务中的某部分内容，只有当确认的或者取消的时候，任务才可能继续完成执行这部分内容。如果该任务在子线程，用循环卡住，如果任务在主线程，用sleep+轮训处理。 你可以参考下处理。
曾经思考这种处理方式，但是会把业务搞得过度复杂，比如，在框架层面提供一个暂停标志，默认不开启，用户可自行决定是否设置为暂停状态，待与后端交互完成后，再将任务设置为继续状态，但是这样做会有一个问题，用户忘记设置就麻烦大了。
@lispking 周末看了下，实际上如果需要添加暂停机制，框架层可以开放一些anchor给开发者。现在框架只是设置一些anchor等待前置任务执行，可以更灵活调整为除了等待前置任务，&上一些开发者的条件，比如你的场景需要窗口确认等。 如果感兴趣可以一下pr或者我后续新增一下就好。
1.0.3已支持，请阅读readMe及sample