支持可选任务场景 about anchors HOT 6 CLOSED

@lispking 明白所述。按照上述场景，选择不同难度时刻，程序在该时刻面临初始化分支的选择，同时需要再该时刻暴露给选择方询问选择分支。实际上这种场景可以处理为，多端分支进行协作就可以了。比如先完成前部分分支初始化，然后回切给选择方，再感觉选择方的选择新增后续的初始化链。
1.0.3版本等待功能实际上可以扩展成所需场景。
实际上anchors更偏向应用初始化场景，应用运行时的任务链初始化的功能比较薄弱，需要用户主动清除已有的 anchors侧运行时信息，但也支持。 有兴趣可以pr 或者 我研究下必要性。 欢迎随时交流

from anchors.

@YummyLau 如果让用户主动清除，实现就比较复杂了，建议在框架层面支持，提供不同的原语方式来解决。

from anchors.

@YummyLau 应用场景还是蛮多的，我认为这块有实现的必要性，比如xx软件的新闻展示，在你选择关注的兴趣点后，每个人看到的内容是不一样，这里面就有一个选择性问题。

from anchors.

比如先完成前部分分支初始化，然后回切给选择方，再感觉选择方的选择新增后续的初始化链。

@YummyLau 如果这样做的话，进入不同流程就要设置不同的任务链，如果每个任务链中还有不同条件的判断，那任务链将会到处编写了，虽然可以解决问题，但是代码看起来不太优雅。

from anchors.

比如先完成前部分分支初始化，然后回切给选择方，再感觉选择方的选择新增后续的初始化链。

@YummyLau 如果这样做的话，进入不同流程就要设置不同的任务链，如果每个任务链中还有不同条件的判断，那任务链将会到处编写了，虽然可以解决问题，但是代码看起来不太优雅。

目前我们有一个线上的app是选择游戏，走不通的游戏逻辑。说一下针对上述我的一些体验。

1. 任务链在需要初始化的时候编写可能才是最好的。如果一开始针对所有流程编写所有任务链，那么业务中新增流程或者改动流程往往需要在全局任务链中进行修改。而任务链在自己的业务场景中编写能跟随业务的改动而调整，能解耦。
2. 其次，不同流程的任务链的依赖往往不会简单的依赖当前任务链头部的前置节点。比如说当执行到P节点的时候，接下来有多个流程，A，B，C，这3个流程的任务链可能是 A1-A2-A3，B1-B2-B3，C1-C2，C3，如果这些任务链中，我们选择了A1-A2-A3，当A3过后又有3个流程中（开始出现多个分叉衍生），当A3结束后存在D1-D2-D3被用户所选且Dx的节点依赖B1-B2-B3时，流程将会变得非常复杂。所以在所需初始化的时候再判断依赖是一个明智的选择。
3. 另外，可能还有一些比较复杂的场景，需要再斟酌斟酌。比如说不同流程被设计成不同的模块或者组件，而模块或者组件的依赖链往往会存在编译依赖，如果把这部分依赖抽离到总的 依赖树中会存在严重的模块耦合等等。
   有兴趣可以加我微信一起讨论~ Ming_Lyan

from anchors.

1.0.5 开放release用于重启新流程，详情页见demo

from anchors.