Skip to content
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 webview restoration api proposal #46380

Merged
merged 6 commits into from
Apr 4, 2018
Merged

Conversation

mjbvz
Copy link
Collaborator

@mjbvz mjbvz commented Mar 23, 2018

From #45994

Adds an experimental API that allows extensions to persist webviews and restore them after vscode restarts. Uses this api to restore markdown previews.

This is done by:

  • Adding a new state field on webviews. This is a json serializable blob of data

  • Adds a new WebviewReviver interface (name will probably change). This binds a specific viewType to a provider that can restore a webview's contents from its state

  • In VS Code core, persist webview editors. When we restart and need to show a webview, activate all extensions that may have revivers using the onView:viewType activation event.

Current implementation is sort of a mess. Will try to clean things up

@mjbvz mjbvz requested a review from jrieken March 23, 2018 02:09
@jrieken
Copy link
Member

jrieken commented Mar 26, 2018

@mjbvz What do you want me to review here? I think we discussed the API and I still think over-eager state synchronisation isn't the way to go but an explicit hook is way better. For the rest - I am not familiar with the code around webview editor et al anymore.

@mjbvz mjbvz added this to the April 2018 milestone Mar 26, 2018
@mjbvz mjbvz changed the title First attempt at webview restoration api Add webview restoration api proposal Apr 3, 2018
@mjbvz
Copy link
Collaborator Author

mjbvz commented Apr 3, 2018

@jrieken Please take a look at the new vscode.proposed.d.ts API. A few questions:

  • How does the serializer api look?

  • Should serializeWebview and deserializeWebview be async?

  • Should our activation events make it clear that these are webview activations? The current activation event is: "onView:markdown.preview". We could change this to something like: "onWebbiew:markdown.preview" or "onView:webview.markdown.preview"

@jrieken
Copy link
Member

jrieken commented Apr 3, 2018

Looks good. Yeah, I think the de/serialise-functions should be async (but maybe time-boxed). We already have the onView-event and for the sake of simplicity I'd stick with that, like onView:markdown.preview

From microsoft#45994

Adds an experimental API that allows extensions to persist webviews and restore them even after vscode restarts. Uses this api to restore markdown previews. This is done by:

- Adding a new `state` field on webviews. This is a json serializable blob of data
- Adds a new `WebviewReviver` interface (name will probably change). This binds a specific viewType to a provider that can restore a webview's contents from its `state`
- In VS Code core, persist webview editors. When we restart and need to show a webview, activate all extensions that may have reviviers for it using the `onView:viewType` activation event.

Current implementation is sort of a mess. Will try to clean things up
@mjbvz mjbvz merged commit dd21d35 into microsoft:master Apr 4, 2018
@github-actions github-actions bot locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants