Skip to content
This repository was archived by the owner on Feb 23, 2024. It is now read-only.

Evaluate if we can update to wordpress/components to or 9.0.0 9.2.0 or later #2140

Closed
senadir opened this issue Apr 7, 2020 · 2 comments · Fixed by #3457
Closed

Evaluate if we can update to wordpress/components to or 9.0.0 9.2.0 or later #2140

senadir opened this issue Apr 7, 2020 · 2 comments · Fixed by #3457
Assignees
Labels
focus: performance The issue/PR is related to performance. type: cooldown Things that are queued for a cooldown period (assists with planning).

Comments

@senadir
Copy link
Member

senadir commented Apr 7, 2020

Is your feature request related to a problem? Please describe.
Currently, we use wordpress-components 8.5 in our project, it introduced a large increase in bundle size since it's not treeshaked, we should aim to upgrade it or remove it completely from our frontend bundle.

If we update to 9.0.0:

  • We get treeshaking, it reduces the bundle size, however dashicon is still included, so we should move away from Panel and Panel body components.

If we upgrade to 9.2.0:

  • We get treeshaking and removed dashicon, we still has to move away from card component since it includes extra dependencies like emotion that increases the bundle size (and bring no value to us).
@nerrad
Copy link
Contributor

nerrad commented Apr 8, 2020

since it includes extra dependencies like emotion that increases the bundle size (and bring no value to us).

Why does it bring no extra value? It's used in the card component to ensure it has a default design. I could also see us using emotion in the future to ensure our components have a base design no matter what theme is in use. Also, is it less weight than dash-icons (I'm guessing yes)?

My vote would be to update to 9.2.0 - but I seem to recall there being other issues when we bumped up components to the latest version. We'll have to do thorough testing.

@senadir
Copy link
Member Author

senadir commented Apr 8, 2020

Why does it bring no extra value? It's used in the card component to ensure it has a default design. I could also see us using emotion in the future to ensure our components have a base design no matter what theme is in use. Also, is it less weight than dash-icons (I'm guessing yes)?

While I'm not against CSS-in-JS, I see actual value in it, but none of us or GB are taking benefit from it, I did a lot of research yesterday into this, mostly talked to Q, Diego and some other to see if we can change it, there is a hold in both calypso and GB until a better solution comes around (facebook yet to be announced CSS-in-JS library), and as long as there is no real shift yet (for the majority of components, or our components) and as long as there are no intent from us to start switching to it, it's simply a dead weight that can easily be recovered with a simple fix.

and also the main issue comes from the runtime addition to it, other libraries offer the same features without sticking around in runtime (causing less bundle overall).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
focus: performance The issue/PR is related to performance. type: cooldown Things that are queued for a cooldown period (assists with planning).
Projects
None yet
3 participants