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

docs(statuslight): docs to storybook migration #3152

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

marissahuysentruyt
Copy link
Collaborator

@marissahuysentruyt marissahuysentruyt commented Sep 23, 2024

Description

This PR continues migrating documentation from the static docs site to Storybook, with a focus on the status light component. When possible, documentation and/or stories were brought over from the S2 status light migration.

  • Added the migration notes to the CHANGELOG
  • Added component description and some control descriptions
  • Added documentation around variant usage
  • Added sizing, semantic and non-semantic stories to showcase all variants of status light

Jira/Specs

CSS-939

This PR has no CSS changes, so no changeset is needed.

How and where has this been tested?

Please tag yourself on the tests you've marked complete to confirm the tests have been run by someone other than the author.

Validation steps

Regression testing

Validate:

  1. The documentation pages for at least two other components are still loading, including:
  • The pages render correctly, are accessible, and are responsive.
  1. If components have been modified, VRTs have been run on this branch:
  • VRTs have been run and looked at.
  • Any VRT changes have been accepted (by reviewer and/or PR author), or there are no changes.

Screenshots

To-do list

  • I have read the contribution guidelines.
  • I have updated relevant storybook stories and templates.
  • I have tested these changes in Windows High Contrast mode.
  • If my change impacts other components, I have tested to make sure they don't break.
  • If my change impacts documentation, I have updated the documentation accordingly.
  • ✨ This pull request is ready to merge. ✨

Copy link

changeset-bot bot commented Sep 23, 2024

⚠️ No Changeset found

Latest commit: acb656f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Contributor

github-actions bot commented Sep 23, 2024

File metrics

Summary

Total size: 4.31 MB*

🎉 No changes detected in any packages

* Size determined by adding together the size of the main file for all packages in the library.
* Results are not gzipped or minified.
* An ASCII character in UTF-8 is 8 bits or 1 byte.

Copy link
Contributor

github-actions bot commented Sep 23, 2024

🚀 Deployed on https://pr-3152--spectrum-css.netlify.app

@marissahuysentruyt marissahuysentruyt force-pushed the marissahuysentruyt/css-939-status-light-docs branch from bafef35 to 599c210 Compare September 25, 2024 14:52
Comment on lines +120 to +127
export const Disabled = Template.bind({});
Disabled.args = {
isDisabled: true,
};
Disabled.tags = ["!dev"];
Disabled.parameters = {
chromatic: { disabledSnapshot: true },
};
Copy link
Collaborator Author

@marissahuysentruyt marissahuysentruyt Sep 25, 2024

Choose a reason for hiding this comment

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

We specifically removed the disabled styles and the disabled variant from the docs page in #1495. There's also no disabled status lights in S2. The only reason I added this is because the guidelines page references a disabled status light state. Perhaps that's out of date?

I have a separate commit for the disabled story and testing for easy removal. If we decide to keep the disabled stuff, I have a draft PR here: #3153 to add the disabled styles back into our CSS.

@marissahuysentruyt marissahuysentruyt marked this pull request as ready for review September 25, 2024 15:04
@marissahuysentruyt marissahuysentruyt added run_vrt For use on PRs looking to kick off VRT ready-for-review size-1 XS ~1-6hrs; nearly trivial, a few hours, could do more than one in a single day. documentation Because documentation is important and shouldn't be broken labels Sep 25, 2024
Copy link
Collaborator

@rise-erpelding rise-erpelding 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 great! I added a couple of my non-blocking thoughts/questions below and we'll need to follow up one way or the other with Disabled, but clearly you've done the work on that and will apply whichever version is needed! ⭐

* Status lights should always include a label with text that clearly communicates the kind of status being shown. Color alone is not enough to communicate the status. Do not change the text color to match the dot.
*
* When the text is too long for the horizontal space available, it wraps to form another line.
*/
Copy link
Collaborator

Choose a reason for hiding this comment

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

May I ask what your reasoning was for not showing the text wrapping to form another line? I think I made the opposite choice in some work I just did for switch, but I'm on the fence on whether I think that's the best way or whether we specifically need to demonstrate text wrapping.

I notice we're testing status light wrapping in the testing preview, which is definitely good, but I'm not sure that necessarily means we need to show it on the Docs page 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I feel like I had a similar conversation with Cassondra about this when I moved the documentation over for another component, but now I'm not sure where that conversation is. In-line alert is like this, where the truncation/wrapping option is only in the test view, and I know I migrated those docs. Maybe that's what I was thinking of? Badge is like this too I see, but then checkbox and radio show wrapping on their docs pages.

I figure at least a call out is good on the docs page. And then people can also test with a long label themselves? I know that's not a very convincing reason/answer!

direction: "column",
content: html`${[
"accent",
"neutral",
Copy link
Collaborator

Choose a reason for hiding this comment

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

I had never noticed before (or maybe I forgot) that the neutral variant is italicized. Clearly that's an intentional design decision, but it's nowhere in the guidelines. Have you ever picked up any historical knowledge about that? I'd love to see some sort of explanation on the Docs page, although I definitely don't think it's a requirement here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't have much historical knowledge as to why it was italics, but I do know that, for S2, the italicization is no longer supported.

Note: The neutral variant of the status light label uses default-font-style rather than italics as in S1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Because documentation is important and shouldn't be broken ready-for-review run_vrt For use on PRs looking to kick off VRT s1 size-1 XS ~1-6hrs; nearly trivial, a few hours, could do more than one in a single day.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants