fix(runtime-core): schedulerJob skip correctly

[edison1105]

close #2768
close #2829
caused by this af95604

after queue.splice(i,1) in invalidateJob,the length of queue will change, resulting in incomplete job execution in flushJobs

[Mr14huashao]

@edison1105，Hi，i find a problem.
The skip attribute is meaningless and becomes undefined during compilation.

if (job && !job.skip)    //The skip is always undefined.

The button still responds properly after the skip is deleted.

export function invalidateJob(job: SchedulerJob) {
  const i = queue.indexOf(job)
  if (i > -1) {
    //queue[i].skip = true
  }
}

Is there a better way to deal with such situations?

[edison1105]

@Mr14huashao
First of all, invalidateJob is to check whether the job of the child update is already in the queue.

If it is already in the queue, it should not be executed repeatedly. It also works if you remove queue[i].skip = true, but the job will be executed multiple times.this is totally unnecessary.

[Mr14huashao]

@edison1105
After the sourceMap test, I find that job.skip is always undefined.
In other words,! job.skip is always true.

if (job && !job.skip)

The job cannot be determined. It is more reasonable to exclude the problem of the af95604 queue[i] = null.
Maybe we should deal with the queue a different way.

[Ryan2128]

Why is this PR still not merged?

[hgm-gx]

临时解决方法：

watch:{
    'targetValue':function(val){
      this.refreshTarget = false
      this.$nextTick(function(){
        this.refreshTarget = true
      })
    },
  },

[LinusBorg]

Hey @edison1105 do you have an idea for a test case?

[edison1105]

Hey @edison1105 do you have an idea for a test case?

done！

[github-actions]

Size report

Path	Size
vue.global.prod.js	40.56 KB (-0.01% 🔽)
runtime-dom.global.prod.js	26.95 KB (0%)
size-check.global.prod.js	16.31 KB (-0.01% 🔽)

[LinusBorg]

There's ongoing discussion about another way to solve this here: #3184

We should resolve that discussion before deciding wether to merge this PR or the other one.

[yyx990803]

I believe #3184 provides a more robust fix for this, but thanks a lot of this PR as it provides important information for #3184 to build upon.