Option to keep documentContentProvider alive when tab is changed

[ivankravets]

We have very bad feedback about VSCode + PIO Home (@platformio). PIO Home is React.JS based application which we load using iframe. It depends on a server backend and needs 1-2sec to be started.

See related issue with detailed description for this problem: platformio/platformio-vscode-ide#32

I've already received a feedback from @Tyriar / @mjbvz that it's a normal behavior of VSCode.

We propose our extensions of PlatformIO IDE for Atom and VSCode. We don't have any problems with Atom, it allows us to decide what to do with an internal content provider.

---

So, how about to have an option for vscode.workspace.registerTextDocumentContentProvider where we can explain VSCode to don't kill our documentContentProvider when a tab is changed?

[mjbvz]

Again, I don't know your code but do you need to block on the server request? Can you cache the state and then update the cached data once server request completes?

previewHtml was never really designed for constructing entire UIs within VSCode. A few extensions are doing this but we haven't done anything special to support it. I think we need to discuss if custom UIs like this are really something we want to endorse and if the html preview really is right way to implement these. This ties into #5604 and #22068

[ivankravets]

1. We don't render content in textDocumentContentProvider. We use iframe and load separate Web-page which is hosted on our built-in/local server (separate Python process). See https://github.com/platformio/platformio-vscode-ide/blob/develop/src/home.js#L31

2. We use the same UI/Application for Atom, VSCode and standalone browser. This approach saves our resources and efforts for maintaining multiple UIs.

3. Our front end part is based on React/Redux stack, where server side lives in a separate Python process. In theory, we can "dump" a state of App before VSCode kills Tab. However, we can't make quick "restore" because VSCode needs 1-2 seconds to load IFRAME again, where we need >1 seconds to establish WebSocket connection with our backend server. Finally, it looks VERY LAGGY :(

My proposition is to don't force developers to use "yet another UI by VSCode" and allows us directly work with DOM without any restrictions. Indeed, we only the one problem "killing of a tab".

[mjbvz]

Thanks for the additional info. Looking through our backlog, it seems already have #28263 to track allowing webviews to persist. I'm going to close this issue as a duplicate of #28263