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

feat: Steps #2684

Merged
merged 31 commits into from
Oct 1, 2024
Merged

feat: Steps #2684

merged 31 commits into from
Oct 1, 2024

Conversation

Revuj
Copy link
Contributor

@Revuj Revuj commented Sep 9, 2024

Description

Related links, issue #, if available: n/a

How has this been tested?

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

  • Changes include appropriate documentation updates.
  • Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
  • Changes do not include unsupported browser features, see CONTRIBUTING.md.
  • Changes were manually tested for accessibility, see accessibility guidelines.

Security

Testing

  • Changes are covered with new/existing unit tests?
  • Changes are covered with new/existing integration tests?

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.


> .step-details {
align-items: center;
font-size: awsui.$font-size-body-s;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

font-size and color should not be set here. I'll remove this

import statusIconStyles from '../../../status-indicator/styles.selectors.js';
import testUtilStyles from '../../../steps/test-classes/styles.selectors.js';

export class StepWrapper extends ComponentWrapper {
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 is WIP but any feedback regarding what selectors we should have is appreciated

Copy link
Contributor

@cansuaa cansuaa left a comment

Choose a reason for hiding this comment

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

As a side note, for type changes to be reflected in documentation don't forget to build the package and then update the documenter snapshot


const InternalStep = ({ status, statusIconAriaLabel, header, details }: StepsProps.Step) => {
return (
<li className={clsx(styles['step-container'], testUtilStyles['step-container'])}>
Copy link
Contributor

Choose a reason for hiding this comment

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

You don't need separate classes. You can use the ones in styles. One minor thing, you also don't need to append step- to the beginning of each class name. Here you can simply use step and below status, header, etc.

}
}
export default class StepsWrapper extends ComponentWrapper {
static rootSelector: string = testUtilStyles.steps;
Copy link
Contributor

Choose a reason for hiding this comment

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

The same case with my comment above, you don't need the testUtilStyles, here you can use styles.root which is usually how it's defined for the other components as well.

return (
<li className={clsx(styles['step-container'], testUtilStyles['step-container'])}>
<div className={clsx(styles['step-status'], testUtilStyles['step-status'])}>
<StatusIndicator type={status} iconAriaLabel={statusIconAriaLabel} />
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems that only icon is being used from status indicator? If we only want to get the icon then why not use the icon component?
Another question, do we expect the text to be the same color as the status icon? e.g. green when status is success?

Copy link
Contributor Author

@Revuj Revuj Sep 9, 2024

Choose a reason for hiding this comment

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

If we only want to get the icon then why not use the icon component?

Good point!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another question, do we expect the text to be the same color as the status icon? e.g. green when status is success?

That is really up to the consumer. There are use cases where consumers want to do that and others where they don't

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's discuss switching it to icon with Kashi as well. If it's an icon, we could even expose the other available icon names and custom icons through url or svg but there could be a specific reason why status indicator was chosen (which could be the point I brought up whether we expect text to be green, red, etc.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we only want to get the icon then why not use the icon component?

I was looking into this and one issue is that the https://refresh.cloudscape.aws.dev/components/icon does not have Loading, so we would need to provide some custom logic for that. Because of that I would propose continuing with using the StatusIndicator. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm true that is lacking but we can easily switch it with a spinner. Though it'd mean some API changes and implementation changes. I'd say you leave it as is right now and then we discuss with Kashi

package.json Outdated
@@ -117,6 +117,7 @@
"prettier": "^3.2.5",
"react": "^16.14.0",
"react-dom": "^16.14.0",
"react-markdown": "^8.0.7",
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need 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.

Not really! I mostly added it because in Q we are gonna be using this so I wanted to validate it works as expected but I can replace it by something else and avoid adding a devDependency here

Comment on lines 12 to 14
findStatusIndicator(): ElementWrapper | null {
return this.findByClassName(statusIconStyles.icon);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure how helpful this would be given it only is an icon

Copy link
Contributor Author

@Revuj Revuj Sep 9, 2024

Choose a reason for hiding this comment

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

Isn't it useful so that consumers can test that their expected status is there?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not really, this would only return an icon element which is alone not enough to communicate the status, besides it won't really indicate the status unless they depend on the class name which is not recommended. If you check status indicator, it also doesn't have a selector for the icon.

@cansuaa cansuaa changed the title Feat steps feat: Steps Sep 10, 2024
Copy link

codecov bot commented Sep 10, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.16%. Comparing base (6c9f530) to head (e599846).
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2684   +/-   ##
=======================================
  Coverage   96.15%   96.16%           
=======================================
  Files         756      759    +3     
  Lines       21303    21329   +26     
  Branches     6895     6896    +1     
=======================================
+ Hits        20484    20510   +26     
  Misses        811      811           
  Partials        8        8           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

return (
<div
{...props}
className={clsx(styles.root, styles.steps, props.className)}
Copy link
Contributor

Choose a reason for hiding this comment

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

props.className?

A minor point is that you don't need two separate classes root and steps, only root is enough

expect(wrapper.findItems()[3]!.findDetails()).toBeNull();
});

test('renders correct status icons', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

This test isn't needed, you are testing if status indicator is putting the icon and the test can't even know if they are correct. Visual aspects like this are tested via visual/screenshot tests

Comment on lines +49 to +51
> :last-of-type > .connector {
display: none;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you check if screenreader is able to find this connector?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Confirmed that it is not able to find it :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Tbh I don't think this page is needed we know the component will be updated when customer updates the steps. It also requires interactivity which won't do much for screenshot tests. I'd say the same thing for the interactive permutations.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So I should just leave the regular permutations.page right?


return (
<ScreenshotArea disableAnimations={false}>
<article aria-live="polite">
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you confirm this announces every change in the steps?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Confirmed :)

@Revuj Revuj marked this pull request as ready for review September 13, 2024 10:19
@Revuj Revuj requested a review from a team as a code owner September 13, 2024 10:19
@Revuj Revuj requested review from jperals and removed request for a team September 13, 2024 10:19
Copy link
Member

Choose a reason for hiding this comment

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

What is this file for?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It contains the styles being used in the permutations page. I can remove it and make it inline css if you'd prefer

* Each step definition has the following properties:
* * `status` (string) - Status of the step corresponding to a status indicator.
* * `statusIconAriaLabel` - (string) - (Optional) Text alternative for the status icon.
* * `header` (react.ReactNode) - Area next to the status indicator of the step.
Copy link
Member

Choose a reason for hiding this comment

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

just (ReactNode)

Suggested change
* * `header` (react.ReactNode) - Area next to the status indicator of the step.
* * `header` (ReactNode) - Area next to the status indicator of the step.

Copy link
Member

Choose a reason for hiding this comment

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

I think the description of header could be improved too, maybe work with Kashi to align how it will be referred to in the usage guidelines


export const InternalSteps = ({ steps, __internalRootRef, ...props }: InternalStepsProps) => {
return (
<div
Copy link
Member

Choose a reason for hiding this comment

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

shouldn't these aria-* properties be on the semantic element, i.e. the ol?

successfulStepsInteractive,
];

const [stepIndex2, setStepIndex2] = useState(0);
Copy link
Member

Choose a reason for hiding this comment

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

This can probably be refactored with a component that manages its own internal state independently, instead of managing 4 almost-identical states in a single component.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is true, but is it worth it at this point? :) It's just an example page

Copy link
Member

Choose a reason for hiding this comment

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

Let's call this non-blocking but a suggestion. Always good to keep things simple for the next one who might work on it.

@@ -6817,108 +6817,6 @@
"integrity": "sha512-9rTIZ4ZjWwalCPiaY+kPiALLfOKgAz5CTi/Zb1L+qSZ8PH3zVo1T8JcgXIIqg1iM3pZ6hF+n9xO5r2jZ/SF+jg==",
"dev": true
},
"node_modules/devtools/node_modules/debug": {
Copy link
Member

Choose a reason for hiding this comment

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

Do you know why these changes in the package-lock.json popped up? If not, can we exclude them from the PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Excluded :)

*
* Each step definition has the following properties:
* * `status` (string) - Status of the step corresponding to a status indicator.
* * `statusIconAriaLabel` - (string) - (Optional) Text alternative for the status icon.
Copy link
Member

Choose a reason for hiding this comment

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

"Text alternative" or "Alternative text"?

@cansuaa cansuaa added this pull request to the merge queue Oct 1, 2024
Merged via the queue into cloudscape-design:main with commit 1686229 Oct 1, 2024
70 of 72 checks passed
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.

4 participants