[Bug] Typing mistake in scope.run

[matthew-dean]

Note: I would classify this as a bug, but there's no clear way to submit repros of TypeScript errors, so I'm placing this here.

In the scope documentation it says this:

The run method also forwards the return value of the executed function

However, in the TypeScript types, it has this:

  run<T>(fn: () => T): T | undefined {

This sets the type to return the type of the return function OR undefined, regardless of whether or not the return value includes undefined. When using this in my code, that meant that returning scope.run() causes a mis-match to the expected return type of the function.

However, what I don't know is if, in actuality, scope.run() can return undefined and the documentation is wrong? So either this is a typing error, or a documentation error.

[LinusBorg]

It's explained in a code comment here:

https://github.com/vuejs/rfcs/blob/master/active-rfcs/0041-reactivity-effect-scope.md#new-api-summary

interface EffectScope {
  run<T>(fn: () => T): T | undefined // undefined if scope is inactive
  stop(): void
}

[matthew-dean]

@LinusBorg What does that mean? If the scope is inactive, would you not get undefined from getCurrentScope? Or is this for an edge case where you've set a variable to getCurrentScope, then asynchronously later called .run(), after the scope has exited? 🤔 . Shouldn't run() throw an error if it's run on an inactive scope?

[LinusBorg]

It's not so much an edge case as you can manually create a scope instance and keep a reference to it around possibly indefinitely. accessing the current scope through getCurrentScope() is not the most common scenario in question.

And yes, it could throw an error, while the current implementation just logs a warning. While we can debate if throwing an error would be the better design here, that's not how it works right now.