Automattic / Automattic/wp-calypso
Editor: API preloading does not work for Simple Sites
- Dominant language
- TypeScript
- Stars
- 12.6k
- Forks
- 2k
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 552
Description
## Context
The block editor uses preloading middleware that outputs API responses onto the page as JS objects to prevent the need for an XHR request once the editor is loaded.
WP Core code that defines preload paths (5.7): https://github.com/WordPress/wordpress-develop/blob/c8a4205394819839ee33fad040d24a4fd355cb23/src/wp-admin/edit-form-blocks.php#L46
Gutenberg middleware js: https://github.com/WordPress/gutenberg/blob/3b31957897302c9274afe259e59d1737098d6f8d/packages/api-fetch/src/middlewares/preloading.js
You can see this in action by searching the page source of the editor: the `wp.apiFetch.createPreloadingMiddleware` function takes an object with all of the preloaded API responses for loading data into the editor.
## Bug
Because wpcom API paths are transformed to use public-api.wordpress.com, using our own api middleware, Gutenberg is not able to take advantage of preloading API requests when loading.
For example the `/wp/v2/types?context=edit` path is preloaded. But the API request for Simple Sites is `https://public-api.wordpress.com/wp/v2/sites/{site_id}/types?_envelope=1&context=edit...`, so Gutenberg's preloading middleware is not able to retrieve the response from the JS object printed out in the page source and makes a separate XHR request as the editor loads.
The impact of this is likely a slower time to load the editor (I haven't specifically measured, but strongly suspect making multiple async requests while loading takes longer than preloading the data).
## Possible solutions
A couple routes that could solve this (may need both)
1. Add our own wpcom specific preloading middleware that looks for the public-api paths (similar to the api fetch middleware we already have)
2. Filter `block_editor_preload_paths` (note, changed to `block_editor_rest_api_preload_paths` in WP 5.8) to add public-api specific paths.
Contributor guide
Research direction
Start by comparing the preload paths from wp-admin/edit-form-blocks.php with the public-api paths handled by packages/api-fetch/src/middlewares/preloading.js and the existing wpcom API middleware. Check the block_editor_preload_paths filter, renamed to block_editor_rest_api_preload_paths in WordPress 5.8. Done means Simple Sites can consume the preloaded responses without the extra editor-load XHR requests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- api, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100