-
Notifications
You must be signed in to change notification settings - Fork 49
Icon exploration v2 #3432
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
base: main
Are you sure you want to change the base?
Icon exploration v2 #3432
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
didoo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a general review of the PR. We're definitely in the right direction, there are still a few things I want to discuss with you to better understand (when you're back).
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
3ff6b1b to
94f6d16
Compare
What do you think of the changes? I believe I've addressed everything. |
didoo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the overall architecture and implementation clicks now. There are a few small things to tweak/fix here and there, but nothing major. We're in a very good spot now, I think.
The next steps for me, before opening a proper PR (or a set of stacked PRs, to ease code reviewing/approval) are:
- address the latest comments
- stress-test a bit more the implementation (I remember in the other PR you had this huge grid of all the HDS icon with a switcher on top, we could add it to the
component/iconpage) - stress-test in a couple of consumer app (HCP/Cloud UI and TFC/Atlas, I would say)
When we're sure that everything works (there may be things we didn't think of) we can start to write down the proposed solution in the RFC, so we can gather feedback from our consumers (I would also ask the FEF team and @meirish for feedback)
What do you think? It's a plan?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI @jorytindall is working on a script that generates a JSON with these mappsings, later we can use his JSON as "source of truth" so design and engineering are in sync
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
| } | ||
| } | ||
|
|
||
| // Generate Registry (JS + Types) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this comment I've found in Carbon is relevant for us, but I wanted to share it with you just in case: https://github.com/carbon-design-system/carbon/blob/main/packages/icon-build-helpers/src/builders/react/builder.js#L75-L84
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
packages/flight-icons/scripts/build-parts/generateBundleSymbolJS.ts
Outdated
Show resolved
Hide resolved
packages/flight-icons/scripts/build-parts/generateBundleSVGJS.ts
Outdated
Show resolved
Hide resolved
didoo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't fully reviewed generateBundleSymbolJS.ts but everything else yes, but everything is great π and I think at this point we can start to think how to open the "official" PR (or PRs, if you think you can split it somehow). Branching from the PR #3237 so you can use directly the hdsTheming service instead of the hdsCarbon service
| const { name } = this.args; | ||
| const registryEntry = IconRegistry[name as HdsIconName]; | ||
|
|
||
| if (this.hdsCarbon.carbonModeEnabled && registryEntry?.carbon) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[note] below it's registryEntry.carbon (without ?), which one is correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're both correct. The second instance just has an assertion above it.
| import type { SafeString } from '@ember/template'; | ||
| import type { IconName } from '@hashicorp/flight-icons/svg'; | ||
| import type Owner from '@ember/owner'; | ||
| import type { HdsIconModule, HdsIconName } from '@hashicorp/flight-icons/symbol-js/registry.ts'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[note] The fact that we have IconName and HdsIconName may lead to confusion, what other name can we think of, for the HdsIconName imported from the registry?
or could we use a Partial of the IconName for the IconRegistry type?
| const shouldUseCarbon = carbonModeEnabled && registryEntry.carbon; | ||
|
|
||
| const loader = shouldUseCarbon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no need to define a temporary variable, we can use directly the evaluation in the ternary
| const shouldUseCarbon = carbonModeEnabled && registryEntry.carbon; | |
| const loader = shouldUseCarbon | |
| const loader = carbonModeEnabled && registryEntry.carbon |
|
|
||
| const loader = shouldUseCarbon | ||
| ? registryEntry.carbon | ||
| : registryEntry.flight[size]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[praise] Neat! β€οΈ
| if (loader) { | ||
| this.iconModule = await loader(); | ||
| } else { | ||
| assert(`Size "${size}" not found for icon "${name}"`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmm, are we sure this is the correct error message for this condition? Probably we can add a bit of logic here to differentiate the different messages for the different cases/errors/fails?
| carbon: (() => Promise<HdsIconModule>) | null; | ||
| } | ||
|
|
||
| export declare const IconRegistry: Record<string, HdsIconRegistryEntry>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[praise] so much simpler than the previous version! π
π Summary
DO NOT MERGE - This PR is a spike with the goal of figuring out the best way to import Carbon icons in to HDS
π οΈ Detailed description
πΈ Screenshots
π External links
Jira ticket: HDS-XXX
Figma file: [if it applies]
π Component checklist
π¬ Please consider using conventional comments when reviewing this PR.
π PCI review checklist
Examples of changes to controls include access controls, encryption, logging, etc.
Examples include changes to operating systems, ports, protocols, services, cryptography-related components, PII processing code, etc.