Lets say you have a computed property that filters and sorts an array of values based on a user's input.
If the user begin filtering values from the array, and the sorting value changes during the computation of the filtering, will the computed property continue the execution of the filtering, or will the computed property jump to the next calculation of the computed property in the queue, with the new sorting value?
Javascript is (essentially) single threaded. That means nothing can even process the fact that a user triggered event occurred until the currently executing synchronous code finishes executing.
You can do something yourself to emulate this, though. Add async pauses where you free up the run loop which allows events to be processed, and then resume and check some cancelation condition, then you may be able to achieve something like you're asking. But that's a lot of code, and unless that filtering is really slow, that's probably a bad idea.
Computed properties will completely finish execution.
If the old Vue.js v2 documentation still holds any relevance, then the following passage indicates how changes result in updates:
[...]Vue performs DOM updates asynchronously. Whenever a data change is observed, it will open a queue and buffer all the data changes that happen in the same event loop. If the same watcher is triggered multiple times, it will be pushed into the queue only once. This buffered de-duplication is important in avoiding unnecessary calculations and DOM manipulations. Then, in the next event loop “tick”, Vue flushes the queue and performs the actual (already de-duped) work.
Given JavaScript is a single-threaded language, this would mean that during any particular "tick" of the event loop, no other actions will be processed until the code execution during this "tick" has finished.
If hypothetically Vue's internal behavior were such that these updates were handled purely asynchronously, then there would be the potential for race conditions between any two event loop ticks, especially if the first tick takes a long time to complete while the second tick finishes quickly. Halting the execution of a computed property part way, even if it were possible, could also result in any side effects normally triggered by the computed property's execution (bad practice, but that's another subject) to not be triggered.
These inconsistencies in behavior would cause all kinds of problems for maintaining consistency in the application state, which is a problem that would make any reactive framework effectively worthless.