watchers for async functions

[brandon942]

Crazy idea, right? Watchers for async functions, the big gap in the current reactive API.
tldr:

import { watchEffect, watchEffectAsync, reactive, ref } from 'vue'
const state = reactive({ name: 'Bob', age: 30 });

watchEffect(async () => {
  console.log('name:', state.name); // is watched
  await new Promise((resolve) => setTimeout(resolve, 1000));
  console.log('name + age:', state.name, state.age); // is not watched
});
setTimeout(() => (state.age = 31), 2000); // will not log the new age

watchEffectAsync(async (resume) => {
  console.log('name:', state.name); // is watched
  await new Promise((resolve) => setTimeout(resolve, 1000));
  resume()
  console.log('name + age:', state.name, state.age); // is watched also
});
setTimeout(() => (state.age = 31), 2000); // will log the new age

watchEffectAsync provides you the resume function. resume() must be manually written after every await so that the dependency tracking system knows that this function is running on the main thread again.
But here's the drawback: Any dependency changes will re-run the whole function. We want to re-run only the parts of the function that are affected by the changed dependencies and avoid doing repeated async work (like requests) for max efficiency.

watchEffectAsync(async (resume, hasChanged) => {
  if(hasChanged(state, "name")){ // this still tracks state.name, even though we skip the code when only age changes
    console.log('name:', state.name); // is watched
    await new Promise((resolve) => setTimeout(resolve, 1000));
    resume()
  }
  console.log('name + age:', state.name, state.age); // is watched also
});

Done. Unfortunately, we have to branch the function manually since the framework can't manipulate the internals of a function and in many cases can't analyze it since js is dynamic. The compiler can automate this in simple cases via static tracking if it sees that resume isn't manually used. But generally these functions must be written with watchEffectAsync in mind.
Now, when skipping code we need to restore the context for the code below because usually it wants variables defined above. Example:

var imageUrls = ref(["...", "..."])
var filter = ref(), crop = ref()
var images = ref()
watchEffectAsync(async (resume, hasChanged) => {
  // fetch images
  var imgs = []
  for(let i=0, i < imageUrls.value.length, i++){ // ofc, this loop can be parallelized on filtered urls but this is just for demonstration
    let blob
    let cache = [] // cached context, always a tuple
    // cached context is tied to the ref; or refs:  hasChanged([ref1, [obj, prop]], cache) // ref1 OR obj.prop
    if(hasChanged(imageUrls, i, cache)){ // if a context is stored or wanted, pass an empty array
      blob = await fetch(imageUrls[i].value);
      resume()
      cache[0] = blob
    }
    else{ // get blob from cache
      [blob] = cache
    }
    // process image
    // One can also pass "other" to ask if any other dependencies have changed which we don't know about here and haven't asked about (eg. dependencies used by inner functions)
    if(hasChanged([filter, crop, "other"], cache = [])){
      // If those "other" changed dependencies were not used in ProcessImage but some other function below, then ProcessImage will simply skip everything. No costs.
      blob = await ProcessImage(blob, {filter, crop}, resume, hasChanged) // provide resume, hasChanged so this async function can also track dependencies and skip most parts
      resume()
      cache[0] = blob
    }
    else{ // get blob from cache
      [blob] = cache
    }
    imgs.push(blob)
  }
  images.value = imgs
});

Additional features: Explicit list of dependencies passed to options to not track, watchAsync() for explicitly whitelisted dependencies.

[jods4]

That's a can of worms.

First notice that resume() leaves a blind spot in Vue observability.

const dep = ref(0);

// dep is a dependency of this effect
watchEffect(() => {
  return fsync();
});

function fsync() {
  return ref.value;
}

// dep is NOT a dependency of this effect, even though it's read inside fasync()
watchEffectAsync(resume => {
  const result = await fasync();
  resume();
  return result;
});

async function fasync() {
  await somePromise();
  return ref.value;
}

The work-around would be to propagate resume in all layers of async functions, which is not something you'd like to do. Maybe the JS AsyncContext proposal would help here but it isn't gonna land anytime soon.

Then there are specs details to flesh out:

• what dependencies are watched during async execution? the previous ones, the partially collected new ones, or none?
• what happens if dependencies trigger during async execution? should a new parallel execution start immediately? or start after the current one completes? or should that trigger be ignored?
• to help with previous point, should we have a mechanism to abort pending async work (i.e. AbortSignal, e.g. to stop an http request)? this would also be handy when the watchEffect is stopped (e.g. when parent component is unmounted).
• what happens if the promise rejects? is the effect stopped, or does it fallback to watching its previous dependencies?

[brandon942]

@jods4 Sure, you have to pass resume() to inner functions which contain a task chain if you want to track dependencies along the whole chain. There is no way around it. I don't see how AsyncContext could help with that.
There are a number of questions that need to be considered and you bring up great points. First of all, a serious implementation would probably need to not only know when the function resumes but also when each fragment ends. So instead of writing resume() after every await:

async function effectFunction(resume){ 
  await resume(/* any expression, promise expected */) // resume wraps the expression
  // or
  return promiseObject.then(resume(/* thenCallback */)) // resume wraps the callback
}

// resume could look like this
async function resume(something){ 
  if(typeof something === "function"){ // expected to be a callback
    // start tracking context
    something()
    // stop tracking
  }
  else{ // promise, or anything else
    // stop tracking
    let result = await something
    // start tracking
    return result
  }
}

• Reentry: Should the function be reentrant? It's the user who decides via options. Default? No, because synchronous functions are always atomic and that's kindof the intuition.
• Dependencies: Usually the set of dependencies that trigger the function is determined after all dependencies have been collected, so after each full execution. That's the default behavior. The alternative is updating dependencies in real time and removing unused ones at the end. Live tracking in reentrant functions sounds fun. Both modes can be implemented.
• Triggers: If the effect function is atomic and is triggered during a run, should another run be queued? If the dependency which has triggered it 1) is yet to be reached within the function then it's unnecessary - but the framework can't know that -> Yes. 2) will no longer be in the set of active dependencies after the current run -> No. If the function is reentrant then every tracked dependency within the active set starts another run when changed.
• Rejection: This is equivalent to an unhandled exception. Cancel the collection and re throw the error.
• Abortion: The user is usually responsible for implementing an abortion functionality for his tasks. But we can leverage the benefits of a wrapping resume() here. A wrapping resume gives us full control over the task chain and allows us to stop it at any point. In the await case we do not await the promise and in the callback case we do not invoke the callback.
• hasChanged(): Returns true if any of the passed dependencies have changed. Only dependencies that are in the active set are considered.
• hasChanged() + cache: A context is only stored if a container array is provided by the user. The passed dependencies are used to automatically create a key for the cached context. The key is made up of dependency ids joined together in the order in which they appear in the list + optionally an explicit id passed by the user: hasChanged([dep1, dep2], [], "myId"). Should an exception be thrown if a key appears twice? It's an error but it's not our error -> No let's not keep track of keys.
• hasChanged() + tracking: If the branch is not taken then the passed dependencies are tracked if they're in the active set of dependencies. Again, if the section within the async function is skipped because its dependencies haven't changed (the ones passed to hasChanged) then only dependencies that have been tracked the last time are collected. If the branch is taken (hasChanged returns true) then the passed dependencies are ignored.