Add ability to tap into `acquireVsCodeApi[get|set]State` mechanism from the extension host side

[eamodio]

VS Code provide some state management for Webviews, but extensions from the extension host side can't really interact with it, other than via deserializeWebviewPanel, where we get access to the persisted state, but then need to manually provide that to the webview by either embedding it into the HTML or sending it later via postMessage. WebviewViews do have a WebviewViewResolveContext that the extension gets on resolve, but again you can't update it and have it serialized with the webview.

VS Code already serializes state to the webviews automatically, but we can't tap into it.

It would be very helpful to be able to pass in intial/bootstrap state when creating a webview (pane or view), and could remove a lot of complexity with getting initial state into a webview

Here are a couple of ideas of a possible API:

• Add a new resolveState callback function to WebviewOptions since that is common to both WebviewPanels and WebviewViews

  export interface WebviewOptions {
     ...
     readonly resolveState?<T>(savedState: T): Thenable<T>;
  }

  • VS Code would then call that function (if provided) during construction of the webview providing the persisted state in savedState and then pass along the updated state

• Alternatively,

  • for WebviewPanels:
    • Add a resolveState callback parameter on createWebviewPanel
  • for WebviewViews:
    • Add a setState function provided to the resolveWebviewView callback
    • Or, a setState method to the WebviewViewResolveContext object provided in resolveWebviewView

• Finally, there could be a getState/setState pair on the Webview itself, but that would "require" (or at least seemingly so) the state to be dynamically updateable -- which isn't really in scope with what I'm asking here.

/cc @mjbvz

[worksofliam]

It would be very helpful to be able to pass in intial/bootstrap state when creating a webview (pane or view), and could remove a lot of complexity with getting initial state into a webview

This rings very true. Of course we have to do this with postMessage and handle that in webview, but it sounds like what you are proposing is a way that we could create a webview and set that data without a lot of overhead (via your suggested resolveState).

It's great to see how the API would solve this problem, but I am curious to what your webview HTML content would look like to handle resolveState too.

[eamodio]

I was thinking more about just having a state property on Webview, like Webview.html, and instead of it needing to be "dynamically updateable", it could work just like Webview.html where the whole webview would be re-rendered (exactly as when the html property is changed). Given that, adding a state property (getter/setter) to Webview would be my preferred proposal. And it actually already exists on the VS Code side, so it shouldn't be hard at all to expose.

@worksofliam Yeah, VS Code already serializes persisted state automatically into the webview, which gets loaded by the script that sets up acquireVsCodeApi, but we can't currently tap into it. So GitLens for instance also serializes "bootstrap" state into the HTML and then sets up postMessage passing for dynamic (or larger) state. And if GitLens stores its state via the getState/setState calls, then the state is getting serialized into the webview twice, once by VS Code and once by GitLens, and then the webview then has to reconcile which one of those states to use (I use timestamps currently).

It's great to see how the API would solve this problem, but I am curious to what your webview HTML content would look like to handle resolveState too.

For this nothing would need to be handled differently than today -- you would still call acquireVsCodeApi() and use the getState/setState methods.

[alexr00]

I'd also really like to have this for GitHub Pull Requests and Issues.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[alexr00]

@mjbvz 5 upvotes seems pretty good for an API request.