You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code in the reconciliator uses spread syntax to copy completion item so that it can add a fallback resolve method from provider. This destroys getters.
It is possible to workaround downstream by defining getters as enumerable but this is suboptimal as these will be immediately materialized (so potentially missing opportunity to be populated from resolve request).
Reproduce
Create a provider which returns a an item with insertText getter
Execute completion
See that insertText is undefined and de-duplication does not work
Expected behavior
Use Object.assign instead of spread syntax
We should test that an instance with getter can be used as completion item
Maybe we should avoid creating a copy of completion object in reconciliator in the first place, and internally return a new wrapper object like:
This has a benefit that we could later extend it with renderDocumentation: () => Element so that both LSP markdown-based and kernel sphinx-based docs are rendered properly.
Or, really do we need a factory for a resolve method in the first place? Could we just pass the provider around?
I think that the intent was to later delete the resolve method to mark object as resolved. I do not have a full solution yet.
Context
JupyterLab version: 4.0.6
The text was updated successfully, but these errors were encountered:
Description
The code in the reconciliator uses spread syntax to copy completion item so that it can add a fallback resolve method from provider. This destroys getters.
jupyterlab/packages/completer/src/reconciliator.ts
Lines 61 to 64 in 1d989ba
It is possible to workaround downstream by defining getters as enumerable but this is suboptimal as these will be immediately materialized (so potentially missing opportunity to be populated from
resolve
request).Reproduce
insertText
getterinsertText
is undefined and de-duplication does not workExpected behavior
Object.assign
instead of spread syntaxThis has a benefit that we could later extend it with
renderDocumentation: () => Element
so that both LSP markdown-based and kernel sphinx-based docs are rendered properly.Or, really do we need a factory for a
resolve
method in the first place? Could we just pass theprovider
around?I think that the intent was to later delete the
resolve
method to mark object as resolved. I do not have a full solution yet.Context
The text was updated successfully, but these errors were encountered: