DocumentCard: Convert to CSS-in-JS

[mikewheaton]

Pull request checklist

• Addresses an existing issue: Fixes DocumentCard: Convert to CSS-in-JS #5408
• Include a change request file using $ npm run change

Description of changes

Updates DocumentCard (and all of its sub-components) to use MergeStyles.

Microsoft Reviewers: Open in CodeFlow

[size-auditor]

Component	Baseline Size	PR Size	Size Change	Bundle Size	Tolerance Level
DocumentCard	268740	270156	1416	🔺	❌
CommandBar	240618	240636	18	🔺	✔️
ComboBox	279103	279121	18	🔺	✔️
DetailsList	252260	252278	18	🔺	✔️
Dialog	235568	235586	18	🔺	✔️
Breadcrumb	240308	240326	18	🔺	✔️
TeachingBubble	230589	230592	3	🔺	✔️
SelectedItemsList	278434	278437	3	🔺	✔️
Pivot	228275	228278	3	🔺	✔️
Dropdown	262638	262641	3	🔺	✔️
ExtendedPicker	207710	207713	3	🔺	✔️
KeytipLayer	205516	205519	3	🔺	✔️
Nav	229080	229083	3	🔺	✔️
SearchBox	225714	225717	3	🔺	✔️
SwatchColorPicker	237745	237748	3	🔺	✔️
Facepile	255982	255985	3	🔺	✔️
MessageBar	228948	228951	3	🔺	✔️
ShimmeredDetailsList	267168	267171	3	🔺	✔️
SpinButton	233009	233012	3	🔺	✔️
Grid	222799	222802	3	🔺	✔️
FloatingPicker	344715	344718	3	🔺	✔️
Pickers	319543	319542	-1	🔻	✔️
PersonaCoin	157009	157008	-1	🔻	✔️
Panel	232902	232901	-1	🔻	✔️
GroupedList	176472	176471	-1	🔻	✔️
Keytip	189870	189869	-1	🔻	✔️

[Vitalius1]

Minor nits and some other stuff which I don't consider them blockers and that's why I approve the PR. Would be nice though to have them all addressed)))

P.S. Did you consider grouping all the components in subfolders? It will be a nightmare to navigate having 4 files for each component in just one folder. I think moving to a different folder also wipes some of the git history or at least makes it harder to look with tools like git blame in VSCode so you decide what to do in this case.

[dzearing]

@aftab-hassan I am curious why so many files are changing just 1 or 3 bytes. Is there some sort of unpredictability here with size auditor, or webpack, or is there some EOF character that is sporadically emitting?

[dzearing]

@mikewheaton The DocumentCard went up 1K in minified size (which maybe could equate to a few hundred bytes gzipped). I'm curious why; was the javascript styling larger than the legacy styling? Or, was there some sort of extra logic added?

@aditima @aftab-hassan We are all on the same page here already, but just another example of how important drilling into bundle size difference is. If you think in the viewpoint of the author (Mike), you'll be curious about why this was; what kind of info would be valuable? (we talked about diffing the code which could help, but really just glancing at per module breakdown (this module added X bytes, this one removed X bytes) would get you a quicker answer.)

There's also a few other things that made it difficult to parse the numbers:

Change: 1498... Is this bytes? is it minified or gzipped? Is this small, medium or large? I don't have good context to know the impact.

Suggestion:

1. List out a unit. E.g. if less than 1024, print out bytes: "42 bytes"
2. Else print out KB: "1.02 KB"

I don't think you need MB or beyond. :)

Also print both minified and gzipped. Or, short term, change the column header to say "minified" just to be clear we're not taking into account gzip optimization.

[mikewheaton]

@dzearing I'm not sure why the bundle size went up. There are a lot of new files, and the style objects are slightly larger than CSS, so it may be a case of a lot of small changes adding up.

@Vitalius1 Thanks for all the feedback! I've made the requested changes, could you take another look?

[Vitalius1]

Approving the PR with some more comments which are not blockers at all and will leave on you to decide if you want to address them.
Great job and thank you for making the changes requested so far 👍

[mikewheaton]

@yiminwu, could you review this PR?

[aftab-hassan]

@aditima @aftab-hassan We are all on the same page here already, but just another example of how important drilling into bundle size difference is. If you think in the viewpoint of the author (Mike), you'll be curious about why this was; what kind of info would be valuable? (we talked about diffing the code which could help, but really just glancing at per module breakdown (this module added X bytes, this one removed X bytes) would get you a quicker answer.)

+1 We spoke offline as well and are on the same page about drilling down by module. That would help the author to know which specific files brought about a change in module, which in turn affected the chunk, and ultimately the asset.

There's also a few other things that made it difficult to parse the numbers:

Change: 1498... Is this bytes? is it minified or gzipped? Is this small, medium or large? I don't have good context to know the impact.

This is bytes minified. David suggested an alternate way of reporting, which we will roll out in the next LightRail PR.

Also print both minified and gzipped. Or, short term, change the column header to say "minified" just to be clear we're not taking into account gzip optimization.

We'll do gzipped as well.

[msft-github-bot]

🎉[email protected] has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Official NPM Release
• Test the release with Developer Demo Site