Support caching remote assets

[crazytonyli]

What?

This is an alternative solution to #107.

Happy path

Here are the steps to see the "happy path" scenario on the Demo iOS app:

1. Create a self-hosted site.
2. Install Jetpack and fully connect to WordPress.com. This is necessary to verify jetpack plugins block types are loaded into the editor.
3. Update the EditorConfiguration.template to use your test site.
4. Run make build.
5. Make sure the GUTENBERG_EDITOR_REMOTE_URL launch argument is unchecked. Launch the Demo iOS app.
6. You should see your site in the "Remote Editors" section of the Demo app.
7. (Optional) Tap the Refresh button to pre-fetch the editor assets.
8. Tap your test site to launch the editor.
9. Open the block inserter and verify the Jetpack blocks (i.e. AI assistant)

Example

Known issues

When enabling GUTENBERG_EDITOR_REMOTE_URL, the fetched assets can be used by the editor, and the editor can be launched. However, the Jetpack blocks (see the happy path scenario) are not available in the block inserter.

Why?

How?

Here is how the caching mechanism works:

1. The GBK editor invokes the fetchEditorAssets JavaScript function to retrieve the manifest from the wpcom/v2/editor-assets endpoint, and eventually renders the returned scripts and styles HTML on screen.
2. The fetchEditorAssets JavaScript function internally calls the iOS native code EditorAssetsProvider to get the manifest content. However, the manifest content is not verbatim from the wpcom/v2/editor-assets endpoint.
3. EditorAssetsProvider calls EditorAssetsMainifest.renderForEditor to swap the HTTP links in the script and link tags with gbk-cache-http(s):// links.
4. After the modified manifest content is returned to the GBK editor, the script and link tags are rendered on screen, and the web view attempts to load those gbk-cache-http(s):// links.
5. The CachedAssetSchemeHandler is triggered to load content for the gbk-cache-http(s):// links. This is where we can fetch and cache the assets from the original HTTP URL.

Difference with #107

The major difference is that #107 caches the editor assets as a whole. But this PR caches the asset individually.

In #107, it stores the hash value (which is proposed in wordpress-mobile/block-editor-assets-endpoint#1) returned by the editor-assets API. When a new download operation is triggered, it gets the hash value from the editor-assets API response. If the value changes, which happens if assets are added or removed, it re-downloads all the assets again, even if some have already been downloaded. Since the editor assets are treated as a complete bundle, the GBK editor can only be loaded after all assets are downloaded.

This PR works with the existing wpcom/v2/editor-assets API, and does not require the hash value. There is an API (EditorAssetsLibrary.fetchAssets) to start downloading the editor assets before launching the GBK editor. But you don't have to wait for the caching to complete; you can launch the editor anytime, and the cache can continue to get to work when users work on their posts. That's because this PR caches assets individually via the gbk-cache-http(s) links (see the "How" section above). The "identifier" of the asset is its URL (the hash used in #107 also uses asset URLs as cache identifiers). A new cache file is created for each asset URL. When new assets are included in the editor-assets API response, they will be cached either by a call to EditorAssetsLibrary.fetchAssets, or when the new assets are rendered in the GBK editor.

Testing Instructions

Verify that the solution works with sites that are

• located under a subdirectory: https://example.com/blog
• using a non-English locale for the whole site and/or the logged-in user.
• The editor functions the same with or without the GUTENBERG_EDITOR_REMOTE_URL launch argument.

Accessibility Testing Instructions

Screenshots or screencast

[dcalhoun]

This looks great. The "happy path" succeed for me. 🎉

When enabling GUTENBERG_EDITOR_REMOTE_URL, the fetched assets can be used by the editor, and the editor can be launched. However, the Jetpack blocks (see the happy path scenario) are not available in the block inserter.

This known issue no longer occurs for me. I am able to utilize Jetpack blocks while using the remote editor dev server.

[crazytonyli]

The font on the web editor and GBK remote editor is not the same. ⬇️

The remote edtiro in the trunk branch also uses a different font. ⬇️

@dcalhoun I guess this is a known issue?

[dcalhoun]

The font on the web editor and GBK remote editor is not the same. ⬇️
[...]
@dcalhoun I guess this is a known issue?

Yes, #81 tracks loading fonts.

[dcalhoun]

This works great from my testing. Thank you for helping design and implement this!

[dcalhoun]

• located under a subdirectory: https://example.com/blog
• using a non-English locale for the whole site and/or the logged-in user.

I'm unsure why these were originally listed in #107 or they might impact this functionality. Presumably any impact would be present in the existing, non-caching fetching mechanism. It likely safe to merge this. WDYT?

At the moment, the l10n is handled in the app, the site/user setting has no impact on GBK. We plan to expand that l10n to include third-party strings later.

[crazytonyli]

I'm unsure why these were originally listed in #107

I added those while reviewing the PR 😄.

I tested with a "subdirectory site", and the editor did not load. I don't think it's related to this PR, though. I have created a Linear issue under the "GutenbergKit supports self-hosted sites" project to track it.