-
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.
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.
@zamoore OK, this lead me to another observation: you dont' need at all to set the viewport to 32px: because of how SVG works, the important thing is that the <symbol> has the correct viewport (32px) for the Carbon icons, here you can leave the standard viewport; which means you can get rid of this whole getter and just use 0 0 ${this.size} ${this.size} directly in the template as we did before
| 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?
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.
We can use IconName directly which cleans up some of the typing. Good suggestion.
|
|
||
| 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! π
d5e2a40 to
84700b5
Compare
9d863da to
370edf0
Compare
alex-ju
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.
Some general consideration on my end β started a few days ago, but took me a while to re-assess today as many of my suggestions were no longer relevant/valid.
The refactored registry structure is a major improvement (grouping icons by base name with nested size loaders reduces registry size in half and creates much clearer separation between size-specific Flight icons and universal Carbon icons. Moving from bundled files to separate /symbol-js/flight/ and /symbol-js/carbon/ folders completely addresses my initial network overhead concern. With HTTP/2 multiplexing and individual file caching, this dynamic loading approach should actually be more efficient than bundled sprites. The simplified regex-based SVG processing and universal 32px Carbon icons with dynamic viewBox adjustment are both elegant solutions.
I think this is now production-ready pending stress testing (ideally with some basic performance metrics). I would personally look for any potential FOUC during async icon loads.
I would also recommend explicitly documenting the fallback behaviour (e.g. when Carbon mode is enabled but no Carbon equivalent exists).
Overall, the architecture is sound, backward compatibility is maintained, and the approach is well-suited for modern HTTP/2 environments. Great work @zamoore and @didoo!
π 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.