就像我上个文章中所讲的,我们当前需要的是一个可以这样调用弹窗子组件的方法。
就比如像上面这个结构,如果我们改变任务1,那么处理顺序应该是如下图所示:
任务1 |
---|
任务1.1 |
任务1.1.1 |
任务1.1.2 |
任务1.1.2.1 |
任务1.1.3 |
任务1.2 |
任务1.2.1 |
任务1.2.2 |
但是我们每次调用相应任务的弹窗只能获得该任务的后置任务,那么我们要怎么保证顺序呢?
第一次:手动修改任务一截止时间调用任务1弹窗,获取任务1.1,任务1.2,反转后压入堆栈,处理任务1.1,此时任务栈:
任务1.1 |
---|
任务1.2 |
第二次:自动处理栈顶任务——任务一,获取后继任务——任务1.1.1,任务1.1.2,任务1.1.3,反转后压入堆栈,处理任务1.1.1此时任务栈:
任务1.1.1 |
---|
任务1.1.2 |
任务1.1.3 |
任务1.2 |
第三次:重复第二次操作,处理后任务栈:
任务1.1.2 |
---|
任务1.1.3 |
任务1.2 |
第四次:获取1.1.2后继,并加入到栈中
任务1.1.2.1 |
---|
任务1.1.3 |
任务1.2 |
第五次:
任务1.1.3 |
---|
任务1.2 |
第六次:
任务1.2 |
第七次:
任务1.2.1 |
---|
任务1.2.2 |
第八次: |
---|
任务1.2.2 |
明白了执行顺序该怎么解决那么又要怎么在前台来按照这个顺序执行——我们可以直接在父组件中设置一个任务数组用来存储和处理弹窗中传来的任务作为上文所说的任务栈来使用。
代码部分就不多赘述,总体大致执行流程如下图:
这么处理我们既可以解决弹窗顺序的问题,也可以解决弹窗如何保证是接连弹出而不是同时弹出多个弹窗的问题。
另外,本周对于此项目编写的最大感受就是——尽最大可能不去修改其原本代码,尽量不在很了解的情况下去使用原项目的写法。
就比如原项目对于状态模式的使用,我们并不是非常了解这种写法,在这种情况下随意调用其原本的代码有可能就会触发一些隐藏的bug,即使是测试时并未发现,由于经验不足,我们也不能确定不会造成其他影响。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。