Summarize the problems encountered this week

Let me talk about the problem scene first, or the pop-up window after the previous adjustment time.
Let me talk about the ideal effect first:

The first thing to explain is that not every task has a successor task. Even if there is a successor task, if the successor task does not meet the conditions (the start and deadline exist), there will be no pop-up window.
At first, I wanted to rely on the pop-up window component to solve the judgment problem-judgment after the pop-up window is opened, and then close the pop-up window if the conditions are not met. Although it can be executed normally, and the pop-up window is basically invisible to the human eye, but many tests Later, I found that the splash screen still appeared, so I gave up this writing method.
Regardless of the order of the pop-up windows, first try to see if the pop-up windows can be called normally.
At first, I thought about calling the batchSettingTime method written before in the parent component to solve it.
First introduce this method:
Required parameters: time before change, time after change, current task, successor task of current task.
This method first obtains the task details of the subsequent tasks of the current task, that is, obtains the start and deadline times of these tasks, and then judges whether there are tasks that need to be displayed in these tasks (the start/deadline time is complete). to call the pop-up window.

batchSettingTime(. . .) {
  // Whether there is a fully configured task in the successor task
  havePostTasksAllDate = false;
  // Subscribe to the task details of all successor tasks
  let ListOgPostTasks = [] as Observable<Task>[];
    task => {
    // Use combineLatest to obtain judgments and obtain all task details before processing
           data => {
               task => {
                    if(task.duedate && task.startDate) {
                      havePostTasksAllDate = true; 
    // If the conditions are met, then call the pop-up window
    if(havePostTasksAllDate) {
        const changeDate = newDate - oldDate;
        const dialogRef =, {Will task,    changedate,oldDate incoming popup})
    // Because if it is called after it is closed, the variables in it cannot be obtained because the pop-up window component has been destroyed, so it needs to be processed before it is closed
    if(dialofRef.componentInstance.selectedTasks.lenth != 0 && dialogRef.componentInstance.beSubmit) {
            task => {
                    .pipe(takeUntile(dialogRef.afterClosed())), skip(1))
                    .subscribe(data => {
                        // Since it is necessary to unsubscribe the old observer in time, unsubscribe when this pop-up window is closed
                        // Since select returns content twice, use skip(1) to skip getting old content
                        postTasks = data;
                                task => {
                                    this.batchSettingTime(task.dueDate - changeDate, task.dueDate, task, postTasks)

At first, because the subscription to was not canceled in time, the subscription would be triggered every time fetchDependentTasks was executed, and the previous subscription would be triggered whenever a new pop-up window was opened, resulting in multiple additional pop-ups of the pop-up window.

In addition, since the select method mentioned above normally triggers twice, you can use a custom variable to get the content of the second time instead of the old content of the first time.

However, writing this way is still not standardized, and it is not convenient to test. If there is an rxjs operator like combineLatest, then there should be an operator similar to only getting the second observable content or skipping the first observable content. , After querying the rxjs official website, I found that there are indeed.

        console.log('Skipping the content sent for the first time')

After testing, it is found that the above code can be executed normally if there is only one task, for example: Task 1 = "Task 2 = "Task 3 = "Task 4

When we change task 1, a pop-up window for task 2 will pop up, if we change task 2, there will be a pop-up window for task 3, and so on.

But when we change multiple parallel tasks, there will be problems—four pop-up windows pop up at one time, and the contents of the pop-up windows also affect each other—the successor of task two appears in the pop-up window of task three, and the successor of task three Appeared in the mission two pop-up window.
The guess is also caused by the multiple executions of fetchDependentTasks in the loop, and the post-tasks of the tasks and the task details of the post-tasks will also be obtained in the pop-up window component, and these are also obtained by the store, and there are multiple Components calling the cache at the same time will cause confusion, so I guess that as long as the problem of multiple pop-up windows is solved, the problem of task confusion in the pop-up window should be solved.

Tags: Front-end

Posted by apacheguy on Wed, 30 Nov 2022 21:37:04 +1030