Devdocs: WordPress components gallery

[sarayourfriend]

Changes proposed in this Pull Request

• Add a new WordPress components gallery page to the devdocs

Testing instructions

• Using an environment that has devdocs enabled, navigate to the new WordPress components gallery and check that each component is represented.

Note that some components are represented through the building of the page itself, for example, Card et co as well as the Flex module were used to build the page, so I didn't feel it was necessary to include them as distinct examples. Actually using them is probably the best way to show that they work.

[matticbot]

Test live: https://calypso.live/?branch=add/wp-components-calypso-gallery

[matticbot]

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

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

name      parsed_size           gzip_size
manifest       +971 B  (+1.4%)     +126 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 (~8290 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-gutenboarding       +59159 B  (+3.4%)    +8144 B  (+1.8%)
entry-login                 +115 B  (+0.0%)      +31 B  (+0.0%)
entry-main                   +57 B  (+0.0%)      +92 B  (+0.0%)
entry-domains-landing        +57 B  (+0.0%)      +23 B  (+0.0%)

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

Sections (~2194 bytes removed 📉 [gzipped])

name                   parsed_size           gzip_size
jetpack-connect            +7820 B  (+0.9%)     +314 B  (+0.1%)
reader                     +5973 B  (+1.0%)    +1062 B  (+0.7%)
post-editor                +5931 B  (+0.3%)    +1222 B  (+0.2%)
devdocs                    +1876 B  (+0.9%)     +185 B  (+0.3%)
checkout                    +602 B  (+0.0%)     -979 B  (-0.2%)
gutenberg-editor            +446 B  (+0.0%)      -47 B  (-0.0%)
signup                      -160 B  (-0.1%)     +240 B  (+0.4%)
settings-writing            -150 B  (-0.0%)     -694 B  (-0.5%)
media                       -131 B  (-0.0%)     -736 B  (-0.6%)
domains                      +99 B  (+0.0%)     -779 B  (-0.3%)
site-purchases               +95 B  (+0.0%)     -483 B  (-0.2%)
purchases                    +95 B  (+0.0%)     -476 B  (-0.2%)
settings                     -43 B  (-0.0%)      -46 B  (-0.0%)
settings-security            +32 B  (+0.0%)      +10 B  (+0.0%)
stats                        +28 B  (+0.0%)     -169 B  (-0.1%)
themes                       +23 B  (+0.0%)       +5 B  (+0.0%)
people                       +23 B  (+0.0%)      +14 B  (+0.0%)
woocommerce                  -19 B  (-0.0%)     -693 B  (-0.1%)
comments                     +18 B  (+0.0%)       +5 B  (+0.0%)
site-blocks                  +17 B  (+0.0%)      +14 B  (+0.0%)
notification-settings        +17 B  (+0.0%)      +14 B  (+0.0%)
import                       +17 B  (+0.0%)      +12 B  (+0.0%)
customize                    -13 B  (-0.0%)      -78 B  (-0.1%)
plugins                      +12 B  (+0.0%)       +2 B  (+0.0%)
jetpack-cloud-pricing        +12 B  (+0.0%)       +7 B  (+0.0%)
google-my-business           +12 B  (+0.0%)       +7 B  (+0.0%)
earn                         +12 B  (+0.0%)     -127 B  (-0.2%)

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 (~213860 bytes added 📈 [gzipped])

name                                                         parsed_size           gzip_size
async-load-design-wordpress-components-gallery                 +899923 B    (new)  +212636 B    (new)
async-load-design-blocks                                         +5964 B  (+0.2%)     +412 B  (+0.1%)
async-load-components-web-preview-component                      +5956 B  (+1.1%)    +1026 B  (+0.7%)
async-load-layout-masterbar-checkout                              +466 B  (+0.2%)      -43 B  (-0.1%)
async-load-post-editor-media-modal                                 +29 B  (+0.0%)      +14 B  (+0.0%)
async-load-signup-steps-plans-atomic-store                         -16 B  (-0.0%)       -7 B  (-0.0%)
async-load-signup-steps-plans                                      -16 B  (-0.0%)       -7 B  (-0.0%)
async-load-extensions-woocommerce-app-store-stats-referrers        +12 B  (+0.0%)       +3 B  (+0.0%)
async-load-design-playground                                       +12 B  (+0.0%)      -86 B  (-0.0%)
async-load-design                                                  +12 B  (+0.0%)      -88 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.

[tyxla]

Great work @saramarcondes!

I think we should ship this as soon as possible, and it will help inform our decisions for any future work, related to global style migrations. Any styling problems or visual glitches should be subject to future work. We can also iterate on the particular examples in future PRs as well.

I've left some nits here and there, but nothing I feel is particularly blocking.

One thing I wanted to ask you was the bundle size changes - do you have an idea why there are changes to sections that don't seem related? Do we just need to recalculate them?

Again, great to see this in Calypso! 🎉

[tyxla]

Not sure why I'm unable to make this work by typing ~ 😉

[sarayourfriend]

Yes, it doesn't seem to work, I think it's potentially one of the things that is broken 😱

[tyxla]

Maybe it's something related to how its popover works? But we can investigate in another PR, I don't consider that a blocker 😉

[tyxla]

Any concern from the gutenboarding point of view from updating this? Should we test anything before shipping? cc @Automattic/luna

[yansern]

I think a quick smoke test is to see if anything breaks on /new. Current link: https://hash-829c18b8bcfddd5cf96dd3c4bfb03dd0b6df309f.calypso.live/new

[simison]

Type issues should fail loudly in CI anyway, no?

[sarayourfriend]

It shouldn't be necessary to smoke test anything given it's just type definition updates right? The @wordpress/components package itself did not get upgraded.

[sarayourfriend]

One thing I wanted to ask you was the bundle size changes - do you have an idea why there are changes to sections that don't seem related? Do we just need to recalculate them?

I have no idea why the bundle size changed for Gutenboarding in this PR. The only thing I can think is that maybe because we're importing all the WP components that some tree-shaking isn't working as expected anymore? Maybe @sgomes would have some insight for how to investigate.

[sarayourfriend]

Putting everything behind async load marginally improved some things but increased the manifest size by a similar amount that it reduced the Gutenboarding size... and it didn't even fix the problem with Gutenboarding getting bigger.

I don't think this is the right solution.

[tyxla]

Putting everything behind async load marginally improved some things but increased the manifest size by a similar amount that it reduced the Gutenboarding size... and it didn't even fix the problem with Gutenboarding getting bigger.

I don't think this is the right solution.

Yeah, I'd doubt that would be a good solution. Components would generally end up being in the entry-main chunk because they would be used in multiple sections and locations throughout the app. Or maybe we could work on an exception for @wordpress/components so they would end up in their own chunk?

[jsnajdr]

I did some research about the entry-gutenboarding chunk group that grew 3.4% parsed size and 1.7% gzipped size after introducing the WordPress components gallery. The difference between the async-load-every-component version and the "normal" one is negligible.

The entire entry-gutenboarding chunk group uses 4 shared chunks, shared with other chunk groups. The number of the chunks is the same before and after, but webpack reshuffled the modules a bit. That's expected, as a lot of code from the @wordpress/* namespace is used in a brand new place.

The entry-gutenboarding chunk group contains exactly the same number of modules both before and after, namely 1865. Some modules were moved from shared chunks to the non-shared entry-gutenboarding chunk or vice versa, but none were added or removed.

I think the entire growth can be attributed to the module concatenation optimization being less efficient after the WordPress comonent gallery is added. For a module to be concatenate-able, it must be used only once, and not referenced from any other chunk. It's just like inlining functions -- there can't be a pointer to an inline function, and using a pointer to a function prevents it to be optimized by inlining.

With the WordPress component gallery, many components that were until now used in only one chunk are now used in two. Therefore preventing their concatenation.

I see two solutions:

• just accept the growth and live with it, treating it as a quirk of an optimization algorithm that we can't influence
• build the devdocs section as a separate webpack compilation, not sharing anything with the main app. By nature, devdocs use a lot of components that are not very related to each other, and would otherwise be used only once in the app. They probably cause more de-optimizations like this.

[simison]

With the WordPress component gallery, many components that were until now used in only one chunk are now used in two. Therefore preventing their concatenation.

Thanks for clear explanation @jsnajdr !

just accept the growth and live with it, treating it as a quirk of an optimization algorithm that we can't influence

I'd be fine with this (cc @Automattic/luna). Considering that we want to move towards using @wordpress/* packages across the board, we'll have more shared usage ahead and cannot really avoid this anyway.

[sarayourfriend]

The difference between the async-load-every-component version and the "normal" one is negligible.

Given that I think the "normal" one is preferrable.

Thanks for the explanation, Jarda. It is super helpful.

[griffbrad]

Thanks for the very detailed explanation about the webpack optimization issue @jsnajdr.

• just accept the growth and live with it, treating it as a quirk of an optimization algorithm that we can't influence

I agree that accepting the cost here is fine. The hope is that we’re going to use these components throughout Calypso so they’ll end up being shared by every entrypoint anyway.

• build the devdocs section as a separate webpack compilation, not sharing anything with the main app. By nature, devdocs use a lot of components that are not very related to each other, and would otherwise be used only once in the app. They probably cause more de-optimizations like this.

This is still probably worth pursuing. devdocs includes many large dependencies that will never be used elsewhere in Calypso. For example, react-live is over 2 MB in size and only useful in the context of devdocs.

[tyxla]

I've rebased this to take advantage of the @wordpress/components stylesheet import that we did in #45724.

[tyxla]

FWIW, lint error and TC build failure are expected - it's happening because we're still using the url package in devdocs. I'm fixing that in #45898. #45898 was merged and I've rebased again. All checks are passing now.

[tyxla]

Just like @griffbrad, I agree both of the solutions @jsnajdr suggested make sense - both accepting the trade-offs and considering moving devdocs to either its own entry point or a totally separate app.

I'm actually happy to ship this already since it will be very helpful as we're working on the global styles migration and we get to use more and more @wordpress/components in Calypso.

Does anyone object to shipping it as-is? cc @Automattic/luna @Automattic/team-calypso

[simison]

@tyxla I'll leave it to your team to decide, thanks for the ping. 👍

Really looking forward to see where this brings us!

[griffbrad]

I agree. Let’s ship it.

[tyxla]

Thanks, @saramarcondes, for the brilliant work here! Also thanks everyone for the feedback! Shipping.