先说一下问题场景,还是对于之前的调整工夫之后再进行弹窗。
先说一下现实的成果:
首先要阐明的就是不是每个工作都有后继工作,就算有后继工作如果后继工作不符合条件 (开始和截止工夫啊都存在) 也不会进行弹窗。
起初想靠弹窗组件来解决断定问题——弹窗关上后进行断定,如果不符合条件再将弹窗敞开,尽管能够失常执行,并且基本上人眼看不进去进行过弹窗,然而屡次试验后发现仍会呈现闪屏的状况,所以放弃了这个写法。
先不管弹窗程序,首先试一下能不能失常调用弹窗。
一开始想的是在父组件中循环调用之前写的 batchSettingTime
办法来解决。
先介绍一下这个办法:
须要的参数:更改前的工夫,更改后的工夫,当前任务,当前任务的后置工作。
这个办法首先获取了当前任务的后置工作的工作详情次要也就是获取了这些工作的开始、截止工夫,再去判断这些工作中是否有须要展现的工作(开始 / 截止工夫齐备),如果有再去调用弹窗。
batchSettingTime(. . .) {
// 后置工作中是否存在配置齐全的工作
havePostTasksAllDate = false;
// 订阅所有后置工作的工作详情
let ListOgPostTasks = [] as Observable<Task>[];
postTasks.forEach(
task => {
ListOfPostTasks.push(
this.taskStore
.dispatch(fetchTaskDetail, task.id))}
)
// 利用 combineLatest 获取判断获取完所有的工作详情后再去做解决
combineLatest(ListOfPostTasks)
.subscribe(
data => {
data.foreach(
task => {if(task.duedate && task.startDate) {havePostTasksAllDate = true;}
}
)
// 如果满足条件再去调用弹窗
if(havePostTasksAllDate) {
const changeDate = newDate - oldDate;
const dialogRef = this.util.thyDialog.open(xxxComponent, {将 task,changedate,oldDate 传入弹窗})
}
// 因为如果在敞开后进行调用的话因为弹窗组件曾经销毁,导致其中的变量获取不到,所以要在其敞开前进行解决
dialogRef.beforeClosed().subScribe
if(dialofRef.componentInstance.selectedTasks.lenth != 0 && dialogRef.componentInstance.beSubmit) {
dialogRef.componentInstance.selectedTasks.forEach(
task => {this.taskDependentStore.fetchDependentTasks(task.id)
this.taskDependentStore.select(TaskDepenDentStore.postDependentTasks)
.pipe(takeUntile(dialogRef.afterClosed())), skip(1))
.subscribe(data => {
// 因为要及时的勾销订阅旧的观察者,所以当此弹窗敞开后勾销订阅
// 因为 select 会返回两次内容,所以通过 skip(1)来跳过获取旧的内容
postTasks = data;
this.taskStore.dispatch(fetchTaskDetail, task.id)
.subscribe(
task => {this.batchSettingTime(task.dueDate - changeDate, task.dueDate, task, postTasks)
})
})
})
}
});
}
起初因为没有及时勾销对 taskDependentStore.select(TaskDepenDentStore.postDependentTasks)
的订阅导致每次执行fetchDependentTasks
都会触发订阅导致每当敞开,关上新弹窗都会触发之前的订阅,从而导致弹窗的屡次额定弹出。
此外因为之前所说 select
办法失常状况下就会触发两次,能够由自订变量来获取第二次的内容而不获取第一次的旧的内容。
然而这么写总归还是不标准,并且也不不便测试,如果有像 combineLatest
的这种 rxjs 操作符,那么应该也会有相似于只获取第二次 observable 内容或者跳过第一次 observable 内容的操作符,查问 rxjs 官网后发现果然有。
xxxObservable
.pipe(skip(1))
.subscribe({console.log('跳过了第一次发送的内容')
})
测试之后发现下面的代码如果在只有只有一个工作的状况下是能够失常执行的,比方:工作一 =》工作二 =》工作三 =》工作四
当咱们扭转工作一,就会弹出工作二的弹窗,扭转工作二就会有工作三的弹窗以此类推。
然而当咱们扭转多个并列工作时就会呈现问题——一次性弹出四个弹窗,并且弹窗中内容也相互影响——工作二的后继呈现在了工作三弹窗中,工作三的后继呈现在了工作二弹窗中。
猜想也还是因为循环中的 fetchDependentTasks
执行屡次导致的,并且在弹窗组件中也会获取工作的后置工作及后置工作的工作详情,并且这些也都是靠 store 获取的,同时有多个组件同时调用缓存就产生了凌乱,所以猜想只有解决多个弹窗的问题,应该就能解决弹窗内工作凌乱的问题。