-
Notifications
You must be signed in to change notification settings - Fork 236
feat: migrate asset to s2 styles and second-gen architecture #5858
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?
Conversation
|
📚 Branch Preview🔍 Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
8500305 to
e550a7e
Compare
e550a7e to
58474d7
Compare
Rajdeepc
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.
Good start!
| } | ||
|
|
||
| ::slotted(*) { | ||
| .spectrum-Asset-image { |
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.
This is a breaking change for the existing behaviour if consumers are slotting an <img> without class.
You can keep this class with a migration shim.
::slotted() { /* same rules */ }
.spectrum-Asset-image { /* same rules */ }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.
but can we not break this for spectrum-two?
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 should try not to treat S2 as a chance to introduce breaking changes unless they’re really necessary. These can have a big impact on adoption for product teams, so it’s worth being mindful about when and why we make them. If a change truly adds more value than the potential disruption, we can definitely go for it
| .fileBackground { | ||
| fill: var(--spectrum-asset-file-background); | ||
| .spectrum-Asset-folderBackground { | ||
| fill: var(--spectrum-gray-200); |
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.
Do these map to the same value? Can you surface up these changes in the PR documentation too for quick reference by reviewers. Its hard to visualize from here
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.
These should be the same values, yes (and they look to be mapped correctly).
Before Cassondra left, she started removing some of the complexity from a chunk of components, asset being one of them. You can see the changes (and remove of the --spectrum-asset- variables) here: https://github.com/adobe/spectrum-css/pull/4257/files#diff-3a87a9f21648ac03bf4532993e3cdf48604b9862efd1c0ea68c3f6c2d44b32b3
In a different PR (that does the same and removes mods and some of the --spectrum prefixed variables for asset list and miller), Cassondra left her reasoning as to why: adobe/spectrum-css#4260 (comment)
Hopefully that's useful! I absolutely agree with @Rajdeepc that we should surface the changes in a changeset. None of these migrations have had a changeset yet. (I asked a similar question in Slack when I was working on status light). Do we have the changeset management situation figured out? I've been out, so it might be and we need a changeset!
marissahuysentruyt
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 don't think I have any true changes to request! I did leave some additional context in response to a few of Rajdeep's comments, though- hopefully they're helpful!
| .fileBackground { | ||
| fill: var(--spectrum-asset-file-background); | ||
| .spectrum-Asset-folderBackground { | ||
| fill: var(--spectrum-gray-200); |
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.
These should be the same values, yes (and they look to be mapped correctly).
Before Cassondra left, she started removing some of the complexity from a chunk of components, asset being one of them. You can see the changes (and remove of the --spectrum-asset- variables) here: https://github.com/adobe/spectrum-css/pull/4257/files#diff-3a87a9f21648ac03bf4532993e3cdf48604b9862efd1c0ea68c3f6c2d44b32b3
In a different PR (that does the same and removes mods and some of the --spectrum prefixed variables for asset list and miller), Cassondra left her reasoning as to why: adobe/spectrum-css#4260 (comment)
Hopefully that's useful! I absolutely agree with @Rajdeepc that we should surface the changes in a changeset. None of these migrations have had a changeset yet. (I asked a similar question in Slack when I was working on status light). Do we have the changeset management situation figured out? I've been out, so it might be and we need a changeset!
|
@TarunAdobe I had one more thing! Looking at the title of this PR, I'm curious if this work is a |
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 went through it more in depth, and I have a few more questions for you. It still looks really great!
I'd like 2 changes I think:
- I think the big thing for me ended up being in the stories file, just keeping the render method in the
metato align with how the other migrated components have it set up currently. - Pretty sure we need a
:hostselector in the CSS that also has thedisplay: flexproperty.
| var(--spectrum-asset-icon-outline-color) | ||
| ); | ||
|
|
||
| .spectrum-Asset { |
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.
The CSS here looks great- matches the S2 code we have in the spectrum-two branch. 👍 🥳
My only question is do we need a selector for :host, giving it the display: flex property? I believe the default display for :host is inline.
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.
| .spectrum-Asset { | |
| :host { | |
| display: flex; | |
| } | |
| .spectrum-Asset { | |
| display: flex; // we would also need this here for the `align-items` & `justify-content` | |
| align-items: center; | |
| justify-content: center; | |
| inline-size: 100%; | |
| block-size: 100%; | |
| } |
| import { ASSET_VARIANTS, type AssetVariant } from './Asset.types.js'; | ||
|
|
||
| /** | ||
| * @slot - The content to render when no `variant` is provided (typically an <img> element) |
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.
There is another JSDoc comment in swc/components/asset/Asset.ts about the @slot that is almost identical to this. Is there a reason to have both? It looks like the content in the swc directory's Asset.ts file is the one being used in the control table when storybook renders.
I'm not opposed to keeping both of them, but I was just curious if we need both, or if some other components should have both.
| * <swc-asset style="block-size: 128px"> | ||
| * <img class="spectrum-Asset-image" src="example.png" alt="Example image" /> | ||
| * </swc-asset> | ||
| * | ||
| * @example | ||
| * <swc-asset variant="file" style="min-inline-size: 150px; block-size: 128px"></swc-asset> | ||
| * | ||
| * @example | ||
| * <swc-asset variant="folder" style="min-inline-size: 150px; block-size: 128px"></swc-asset> |
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.
For these examples, do we want to encourage setting inline styles with the style attribute? Or is that more often what consumers would do? Maybe we could show just one example with inline styles.
I don't think this is a blocker, but I just noticed each one had inline styles.
|
|
||
| export const Default: Story = { | ||
| render: (args) => html` <swc-asset variant="${args.variant}"></swc-asset> `, | ||
| render: (args) => template(args), |
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.
Just for consistency, I believe the preference Gray was trying to establish is to include this render in the Meta object. So this line would move up under argTypes (line 42).
Then, we can clean up each story by just redefining args:
| render: (args) => template(args), | |
| // @ line 42 | |
| render: (args) => template(args), | |
| ... // the rest of the metadata and the default export... | |
| export const Default: Story = { | |
| args: { | |
| variant: undefined, | |
| }, | |
| }; | |
| export const File: Story = { | |
| args: { | |
| variant: 'file', | |
| }, | |
| tags: ['!dev'], | |
| }; | |
| export const Folder: Story = { | |
| args: { | |
| variant: 'folder', | |
| }, | |
| tags: ['!dev'], | |
| }; |
That does however, remove the inline styles you have on the stories, but are those inline styles necessary? Does this so acceptable to you?
Description
This PR migrates the next-gen Asset component to Spectrum 2 styles and updates Storybook accordingly.
Motivation and context
This PR migrates the Asset component from first-gen to the second-gen architecture, following the established pattern of separating core component logic from Spectrum-specific implementation.
Changes:
What changed
First-gen:
first-gen/packages/asset/src/Asset.ts- Remains unchanged for backward compatibilityCore (Base):
second-gen/packages/core/components/asset/Asset.base.ts- Updates shared functionalitiessecond-gen/packages/core/components/asset/Asset.types.ts- Creates types file for size and static color variantssecond-gen/packages/core/components/asset/index.ts- Imports and exports typesSecond-gen:
second-gen/packages/swc/components/asset/Asset.ts- Updates render method to accommodate classessecond-gen/packages/swc/components/asset/asset.css- Adds CSS fromspectrum-csssecond-gen/packages/swc/components/asset/stories/asset.stories.ts- Adds comprehensive story coverageRelated issue(s)
Screenshots (if appropriate)
Author's checklist
Reviewer's checklist
patch,minor, ormajorfeatures (Note: I did not add a changeset, I wasn't sure that this was set up for barebones and didn't see any for progress circle or badge, but I'm happy to add one if I'm mistaken!)Manual review test cases
Run second-gen Storybook:
Storybook functionality:
Documentation:
First-gen verification (use the PR preview or run locally):
yarn start # or yarn docs:startCode review checklist:
Device review