Get variable info with background thread #15495
Conversation
| codeWithReturnStatement: string[], | ||
| token: CancellationToken | ||
| ): Promise<T | undefined> { | ||
| return execCodeInBackgroundThread(kernel, codeWithReturnStatement, token); |
There was a problem hiding this comment.
Just noticed this PR, and wanted to provide some quick feedback,
We try to avoid injections where possible, as this slows the extension startup.
In this case you can just keep the class, but remove teh `@injectable decorator
& construct the class when you need it, or just pass it from the calling code
Or remove the class entirely and just use the function, I'm assuming you need the class for mocking/testing purposes
Else having this class is not necessary, as it just wraps a function
For instance today we don't use this class in other places, but use the function directly.
Personally prefer to remove this class and keep the function, else there are two ways of doing the same thing
@rebornix /cc thoughts?
There was a problem hiding this comment.
I need it to work around import zone restrictions - the function is in standalone (which doesn't seem right to me, but it depends on the API code which is also in that zone), and the caller is in kernel. Neither of those zones can depend on the other.
There was a problem hiding this comment.
Ah yes, then please feel free to move the function out of standalone.
Or leave this as is and I'll fix that later,
There was a problem hiding this comment.
+1 for avoiding injectable if possible. This is a static helper function that can be optimized by bundlers, making it an injectable function doesn't seem to give us any benefit at this moment.
Reading the dependencies of execCodeInBackgroundThread, it seems we can move it into kernel component. src\kernels\execution\helpers.ts might be a good place.
There was a problem hiding this comment.
I can do that, and you can keep this pr as is . Or feel free to make the change.
I'm fine with either
There was a problem hiding this comment.
I missed that const api = createKernelApiForExtension(JVSC_EXTENSION_ID, kernel); which depends on NotebookKernelExecution#onDidReceiveDisplayUpdate. It needs some code movement to make it happen. Like @DonJayamanne suggested, probably we leave it to him for the refactoring.
Fixes #15485
5b84fba might be going against the intention of code dependency restrictions, but I seem to need to have a dependency from kernels -> standalone Api,