Site Editor on WP.com: Initial explorations, take two

[ockham]

Rebased version of #39373. Relevant for discussions around a server-decoupled Gutenberg (such as p9oQ9f-iN-p2).

cc/ @saramarcondes

Original PR desc below.

---

Changes proposed in this Pull Request

Take two of #36771.

For context, see pbAok1-dh-p2#comment-589

I'm customizing apiFetch, based on D37093-code. This might be generic enough to make sense across Calypso -- all apiFetch requests made there should go through the WP.com proxy, change the root to public-api.wordpress.com, add /sites/123456, etc.

TODO

• Use promisified request from wpcom-proxy-request (rather than from data-stores) once wpcom-proxy-request: Return Promise if no callback specified #39683 has been merged.

Testing instructions

Go to http://calypso.localhost:3000/custom-editor

cc @Automattic/cylon

[matticbot]

Test live: https://calypso.live/?branch=add/custom-edit-post-take-three

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Webpack Runtime (~110 bytes added 📈 [gzipped])

name      parsed_size           gzip_size
manifest       +370 B  (+0.6%)     +110 B  (+0.8%)

Webpack runtime for loading modules. It is included in the HTML page as an inline script. Is downloaded and parsed every time the app is loaded.

App Entrypoints (~611403 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-custom-editor     +2319097 B    (new)  +609294 B    (new)
entry-gutenboarding       +17836 B  (+1.0%)    +2166 B  (+0.5%)
entry-main                   +96 B  (+0.0%)      +27 B  (+0.0%)
entry-domains-landing        -77 B  (-0.0%)      -77 B  (-0.0%)
entry-login                  -38 B  (-0.0%)       -7 B  (-0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~2621 bytes added 📈 [gzipped])

name              parsed_size           gzip_size
gutenberg-editor      +4354 B  (+0.5%)     +453 B  (+0.2%)
checkout               +476 B  (+0.0%)      -49 B  (-0.0%)
post-editor            +302 B  (+0.0%)      -55 B  (-0.0%)
jetpack-connect        +252 B  (+0.0%)      -78 B  (-0.0%)
home                   +216 B  (+0.1%)      +23 B  (+0.0%)
settings                +92 B  (+0.0%)     +652 B  (+0.6%)
media                   +92 B  (+0.0%)     +656 B  (+0.6%)
devdocs                 -77 B  (-0.0%)      -41 B  (-0.1%)
settings-writing        +68 B  (+0.0%)     +664 B  (+0.6%)
woocommerce             -45 B  (-0.0%)     +396 B  (+0.1%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~224 bytes added 📈 [gzipped])

name                                         parsed_size           gzip_size
async-load-layout-masterbar-checkout              +476 B  (+0.2%)     +174 B  (+0.3%)
async-load-components-web-preview-component       +398 B  (+0.1%)      +73 B  (+0.1%)
async-load-blocks-inline-help-popover             +216 B  (+0.1%)      +26 B  (+0.0%)
async-load-design-blocks                          +208 B  (+0.0%)      -49 B  (-0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[sarayourfriend]

This whole module is very interesting. Any ideas how we would be able to get this to work server-side? Where would the middleware be able to get the current site ID from? Is this already solved elsewhere?

[ockham]

This whole module is very interesting. Any ideas how we would be able to get this to work server-side?

Could you elaborate? We could probably implement those endpoints in PHP and pass through to the 'actual' ones. I'm not quite sure why we would do that, since it seems it would require us to keep a much more explicit list of existing endpoints (which would mean higher maintenance burden etc) 🤔

Where would the middleware be able to get the current site ID from? Is this already solved elsewhere?

I lifted this stuff mostly from the gutenberg-wpcom plugin, and that's using a _currentSiteId global that's attached to window somehow by another plugin (I think).

Alternatively, I think that on the client side, we should be able to store the current site ID somewhere in Redux/@wordpress/data state and have the middleware pull it from there.

[sarayourfriend]

By "server side" I meant the Calypso Node server, in the case of SSR, for example.

[ockham]

Ahh, sorry for misreading. I haven't really thought about that yet TBH. It's true that a lot of @wordpress/ packages don't work particularly well on the server side, but we might be able to make them. (Here's an old exploration by a Team Calypso alum: WordPress/gutenberg#16227.)

[github-actions]

This PR has been marked as stale due to lack of activity within the last 30 days.