Create WebViewProvider API

[tjcouch-sil]

We need to change the way the web view api works so the renderer can reach out and get web views from the backend for the following benefits:

1. Changing layouts is possible
2. WebViews can have persistent state
3. Possibly embed WebViews in each other
4. WebViews persist through refreshing the page
5. Can open multiple of the same type of WebView if the extension allows

We need a WebViewProvider (or WebViewDeserializer or something) API similar to VSCode's WebViewPanelSerializer (example) that is a network object that has a method to deserialize a webview (aka provide the information needed to create the webview. Primarily the react function component or the html page) based on the state given to it (if we want to do this state thing).

Then the web view service would run these when it is loading its layout, then pass them into the dock layout react component once it gets the results.

The general flow would be according to the following very rough design diagram:

It seems to make sense also that we would have some web view service function or something that creates a panel with a specified web view type (similar to the current addWebView command, but you don't have to provide the contents. Just the panel/layout properties and the webview type). In that, the webview service would reach out to the appropriate WebViewProvider to get the actual web view information to display it.

[tjcouch-sil]

To do:

• No more including content in OnDidAddWebView event
• No more including content in webViewService.addWebView
• Web View Provider provides content for a WebView
• Types distinguish different kinds of WebViews
• Some way to open a new webview
• WebViews persist through refresh
• WebView state?

[tjcouch-sil]

WebView state split off to #222

[tjcouch-sil]

Created pull request on rc-dock for patch applied to enable finding tabs by webViewType ticlo/rc-dock#208

[irahopkinson]

After this was first merged (PR #225), we see a number of errors in the browser console:

[tjcouch-sil]

After this was first merged (PR #225), we see a number of errors in the browser console:

I have seen this recently as well in Paranext and in developing my own application. I think it is possible that the owner of the api added throttling to his api, and we are hitting that throttle limit. We may want to reach out to the owner of the api to discuss the situation with him, just stop using the api (maybe @lyonsil could implement the data provider in C# instead ;) ), or temporarily host our own (seems like overkill). It may be worth discussing what we want to do moving forward. Could we close this issue again and open a new issue about figuring out what to do about bible.api?

[irahopkinson]

It could just be a throttling issue with the site we are hitting. However, the first error is a CORS issue and it would surprise me if throttling caused that (but it might). If we can demonstrate that it's just a throttling error then this issue is done. Do you have any thoughts on how we could do that? Like, do you get those errors when you are completely offline? If you do and you go back to main before this PR was merged do we still see the same errors when offline?

[irahopkinson]

Hmm... as a data point, I just ran up Rolf's PR#245 and didn't see any of those errors at first. However a restart (trivial change to main.ts) produced one set of the 3 errors. A full restart of npm start produces the errors again.

[tjcouch-sil]

Created #258 for CORS issues.