-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add proposed webview view API #104601
Add proposed webview view API #104601
Conversation
@@ -226,19 +236,76 @@ const viewsExtensionPoint: IExtensionPoint<ViewExtensionPointType> = ExtensionsR | |||
jsonSchema: viewsContribution | |||
}); | |||
|
|||
|
|||
export interface IViewResolver { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sandy081 Here's an explanation of the changes I made in the views file:
-
View contributions now have an optional
type
. This can either betree
orwebview
.It would be great if we could determine this automatically for extension authors but I wasn't able to find a clean way to do so.
-
The
viewsExtensionPoint
can now generate tree views and webview views.It selects which view to use based on the
type
-
In order to avoid a cycle, I added the new
IViewResolverRegistry
.This is a registry that maps view types to resolvers. A resolver takes a
IViewDescriptor
and fills in the missing details, such as the specific type of view to use. -
I updated
viewExtensionPoint
to register the resolver for tree views.This resolver should do the exact same thing
viewExtensionPoint
previously had hardcoded -
The webview then registers a new resolver for webview based views.
You know this code much better than I do so let me know if you have other suggestions on how this could be accomplished. The main thing is that the viewExtensionPoint
cannot import any webview code since webviews are at a higher level in the codebase
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great if we could determine this automatically for extension authors but I wasn't able to find a clean way to do so.
It is cool but I think it adds confusion and complexity. It is clear if extension declares a tree/web view and creates the same using API.
Note: We need to validate if extension is creating the correct type of view for what it declared.
In order to avoid a cycle, I added the new IViewResolverRegistry.
This is a registry that maps view types to resolvers. A resolver takes a IViewDescriptor and fills in the missing details, such as the specific type of view to use.
Not sure if I understood the need for this resolver and why there is a cycle? For web view type, you have to pass the WebviewViewPane
to ctorDescriptor
, may I know where we have cycle here?
CCing @alexr00 as she owns custom tree views
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cleaned up the implementation so that this is no longer required. The changes in the view code should be much more minimal now
For microsoft#46585 This adds a new `WebviewView` proposed api to VS Code that lets webview be used inside views. Webview views can be contributed using a contribution point such as : ```json "views": { "explorer": [ { "type": "webview", "id": "cats.cat", "name": "Cats", "visibility": "visible" } ] }, ```
@@ -226,19 +236,76 @@ const viewsExtensionPoint: IExtensionPoint<ViewExtensionPointType> = ExtensionsR | |||
jsonSchema: viewsContribution | |||
}); | |||
|
|||
|
|||
export interface IViewResolver { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great if we could determine this automatically for extension authors but I wasn't able to find a clean way to do so.
It is cool but I think it adds confusion and complexity. It is clear if extension declares a tree/web view and creates the same using API.
Note: We need to validate if extension is creating the correct type of view for what it declared.
In order to avoid a cycle, I added the new IViewResolverRegistry.
This is a registry that maps view types to resolvers. A resolver takes a IViewDescriptor and fills in the missing details, such as the specific type of view to use.
Not sure if I understood the need for this resolver and why there is a cycle? For web view type, you have to pass the WebviewViewPane
to ctorDescriptor
, may I know where we have cycle here?
CCing @alexr00 as she owns custom tree views
By moving the webviews view into their own fodler, I was able to avoid the cycle the resolver was originally introduced for
This change should now be content complete and ready for review @alexr00 I'll remove cat example view from the image preview before check in |
Custom tree view related/adjacent changes look good. |
</body> | ||
</html>`; | ||
|
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this won't be merged ;-)
src/vs/vscode.proposed.d.ts
Outdated
* | ||
* @return Optional promise indicating that the view has been fully resolved. | ||
*/ | ||
resolveWebviewView(webviewView: WebviewView, context: WebviewViewResolveContext, token: CancellationToken): Promise<void> | void; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Return Thenable
instead
Not sure if I missed this validation - checking if extension is registering tree data provider to the tree view type and the same for web view? |
Made the suggested changes. @sandy081 Registering a tree data provider for a webview based view will be treated the same as if you never registered the provider at all. I think this is reasonable behavior but if we see that extension authors are confused by which type of view to use, we could look into adding a better error message |
Merging the initial work. Will continue to iterate on the implementation and polishing the API |
Is this api going to be available in Stable 1.49.0 with |
Yes it should already be available in the latest insiders. See https://github.com/microsoft/vscode-extension-samples/tree/master/webview-view-sample for an example extension |
For #46585
This adds a new
WebviewView
proposed api to VS Code that lets webview be used inside views. Webview views can be contributed using a contribution point such as :