Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break up the component-library into smaller modules #1200

Merged
merged 38 commits into from
Jul 9, 2020

Conversation

jaronheard
Copy link
Contributor

@jaronheard jaronheard commented Mar 7, 2020

Summary

This pull request breaks up the component-library into smaller packages, with the intention of replacing and deprecating the component library in favor of these smaller modules.

It leaves the current component-library architecture as the default for now, so all components are now duplicated across packages. The plan for moving to the new components will be detailed in an upcoming RFC.

New packages

Packages Description Dependencies Dev Dependencies Comments
ui-brand Brand assets ui-themes, utils ui-docs
ui-cards Story cards ui-brand*, ui-core, ui-themes, utils ui-charts ui-brand: Logo used for loading spinner
ui-charts Charts components ui-brand*, ui-themes, utils ui-brand: Logo used for loading spinner
ui-core Common UI components ui-themes, utils
ui-docs Style guide and Storybook styles ui-themes ui-brand
ui-maps Map components ui-brand, ui-charts, ui-core, ui-themes, utils
ui-themes Themes and common styles
utils Utilities

Next steps

  • Ensure that the packages are broken out in a way that makes sense 
  • Add read-me to all packages, adjust documentation
  • Fix errors
  • Make it possible to run Storybook for component-library (yarn new-storybook)
  • Ensure that the correct version of Storybook is published to the web

Future work

@jaronheard jaronheard changed the title Component library anti trust Break up the component-library into smaller modules Mar 7, 2020
@jaronheard
Copy link
Contributor Author

jaronheard commented May 17, 2020

Per discussion with @DingoEatingFuzz, making the following adjustments:

  • Removing ui-labs, in favor of developing within project packages and marking components experimental
  • Removing ui-platform in favor of developing within project package
  • Will check to see the size of ui-cards and ui-core? Could they bundled?

@jaronheard jaronheard requested review from a user and DingoEatingFuzz May 25, 2020 20:54
@ghost
Copy link

ghost commented May 25, 2020

I can't provide the caliber of technical review that @DingoEatingFuzz can, so I'll focus on participatory design aspects. These are probably the kinds of things that I'd put in an RFC about the migration process:

  • Should we transition all apps using the existing component library to this modular version and completely remove the old library? It would be ideal to preempt confusion about which library to use and I could see a newer dev thinking it's maybe easier to use the all-in-one-place-but-deprecated-and-enormous library. Alternatively, if migrating all apps using the deprecated library is hard, this could probably be accomplished with good documentation, but they'll need to be migrated over eventually anyways if we want them to benefit from component library updates (and keep our brand identity synced across apps)
  • I'm a bit concerned about having READMEs that just contain links to storybook because contents and instructions may be different for different versions. Also, they aren't even linked to specific storybook areas — perhaps those structures should line up? The READMEs should probably contain at least basic pertinent info and then link out to storybook with a message like "see the latest version and how to use it on storybook"

@jaronheard
Copy link
Contributor Author

jaronheard commented May 26, 2020

@Dianna, thanks for the review! In response to your bullets:

Should we transition all apps using the existing component library to this modular version and completely remove the old library?

See #1207 for details on your first bullet, and let me know if you have further comments after reviewing that.

I'm a bit concerned about the READMEs (sic)

Agreed, I'll flesh out the READMEs per your suggestion. I did the minimum viable READMEs as part of my first PR with the expectation that I'd fill them out a bit once we knew how everything was shaking out, so thanks for the reminder.

Copy link
Contributor

@DingoEatingFuzz DingoEatingFuzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking really good!

I only had a couple things I wanted to ask about.

  1. There are some duplicated files across packages. Are those intentional or by accident?
  2. What's the deal with the .toMove files? Is that part of a multistep rollout or something?

Before this merges, I'd like to get some before and after package sizes as a comment on this PR for posterity.

Oh, also, like @Dianna said, the READMEs need to get better 😛 Deep-linking to parts of Storybook are a start. Using Docs mode within Storybook would make it even better, IMO. Even simple paragraphs that answer "why does this package exist" would be good.

I am okay with that all coming later though. Having PRs this large be open for this long is also not so good for participation (I say that knowing full well I am the problem there).

All in all great work and a huge undertaking!


// chai setup
chai.use(sinonChai);
chai.use(require("chai-enzyme")());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All this mocha stuff isn't necessary if the package doesn't have tests. There's probably also a good way to share this conf—or parts of it—with other packages.

"modules": "es/index.js",
"scripts": {
"build:esm": "rimraf es && babel src --out-dir es --copy-files --no-comments",
"build:cjs": "rimraf dist && babel src --out-dir dist --copy-files --no-comments",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be nice to get to the point where we don't need to different build targets like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be addressed in #1208

"build:esm": "rimraf es && babel src --out-dir es --copy-files --no-comments",
"build:cjs": "rimraf dist && babel src --out-dir dist --copy-files --no-comments",
"build": "BABEL_ENV=esm yarn run build:esm && BABEL_ENV=cjs yarn run build:cjs",
"configure": "yarn run build",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect this is copied from another package so I won't scrutinize but I think some of these scripts can be rethought and maybe trimmed back.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be addressed in #1208

@@ -0,0 +1,3 @@
console.log(
"`yarn start` doesn't work here. Maybe you meant to run `yarn storybook` at project root?"
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these commands are just going to log a line, you can use an echo directly in the package.json file.

"scripts": {
  "start": "echo '`yarn start` doesn\'t work here. Maybe you meant to run `yarn storybook` at the project root?'"
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be addressed in #1208

L328.1,122.7z"/>
<path class="st1" d="M0.1,0.1l10.5,10.5h317.5v112.1l10.5,10.3V0.1C338.6,0.1,0.1,0.1,0.1,0.1z"/>
</g>
</svg>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these SVGs also need to be here if they are in ui-brand? Is the intent to keep ui-charts from being bloated by superfluous ui-brand content?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently there was a whole unused assets folder in ui-charts being useless...

"whatisyourorganization": "Hack Oregon - 2019 Project Season",
"whoareyou": "Stephen Osserman, Nick Kobel, Xander Blair"
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these metadata json files need to be in both ui-cards and ui-charts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently there was a whole unused assets folder in ui-charts being useless...

import MaterialButton from "@material-ui/core/Button";

import { ThemeProvider } from "@material-ui/styles";
import { MaterialTheme } from "@hackoregon/ui-themes";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you run numbers yet on how large ui-core is now? I'm curious how much weight material, emotion, and our ui themes adds.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be right?
image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole measuring things ad-hoc is a little problematic. I'd like to put in some automated checks for bundle size and performance.

@jaronheard
Copy link
Contributor Author

jaronheard commented Jun 15, 2020

  1. There are some duplicated files across packages. Are those intentional or by accident?

The duplicated files that you identified was accidental. I've removed the extraneous asset folder that existed in ui-charts

  1. What's the deal with the .toMove files? Is that part of a multistep rollout or something?

Yep, rather than update 2018 to use the new components now, I'm going to do that in a separate PR. The components that will live within 2018 are in a temporary .toMove folder, and will live within src in the future.

The tarball size comparison[1]:
image

image

  1. For some reason Bundlephobia fails on the component-library ... I was able to get a direct comparison using this tool.

@jaronheard
Copy link
Contributor Author

Ok, I think this is ready now -- the comments have either been resolved, or incorporated into #1207.

@jaronheard jaronheard merged commit 8bf84ec into master Jul 9, 2020
@jaronheard jaronheard deleted the component-library-anti-trust branch July 9, 2020 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants