-
Notifications
You must be signed in to change notification settings - Fork 106
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(progress-bar-expressive): new module #2141
Conversation
🦋 Changeset detectedLatest commit: d464793 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
bef0a16
to
8d2f302
Compare
src/components/ebay-progress-bar-expressive/test/test.browser.js
Outdated
Show resolved
Hide resolved
45df792
to
c80d646
Compare
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.
LGTM overall, just a couple of comments
src/components/ebay-progress-bar-expressive/test/test.server.js
Outdated
Show resolved
Hide resolved
src/components/ebay-progress-bar-expressive/test/test.browser.js
Outdated
Show resolved
Hide resolved
const customA11yText = "Custom"; | ||
const { getByLabelText, getByRole } = await render(template, { | ||
a11yText: customA11yText, | ||
}); | ||
const progressBar = getByRole("progressbar"); | ||
expect(progressBar).to.equal(getByLabelText(customA11yText)); |
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 would swap this to a snapshot test, like
await htmlSnap(default, {a11yText: "Custom"});
export const Localized = Template.bind({}); | ||
Localized.args = { | ||
a11yText: "Cargando...", | ||
messages: [ | ||
{ text: "Espera..." }, | ||
{ text: "Estamos procesando tu pedido", duration: 2000 }, | ||
{ text: "Sólo un momento más" }, | ||
], | ||
}; |
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.
One thing we have been trying to do is have a localized.marko
template in examples, and importing that directly.
I know we have this sprinkled everywhere, but going forward we want to do this method since its much more explicit when showing the code
See
https://github.com/eBay/ebayui-core/blob/master/src/components/ebay-menu-button/menu-button.stories.ts#L237-L241 and https://github.com/eBay/ebayui-core/blob/master/src/components/ebay-menu-button/examples/icon-with-text.marko
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.
Ah yes, that is more explicit! I'll update, though it looks like I will also need to explicitly pass args so the Storybook control panel has the correct initial values. Are there plans to update the buildExtensionTemplate
utility to automatically pull initial args from the example component?
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.
In order to link the strorybook args in the template with the component, you need to spread input into your component (like that example is showing). You also need to emit each event up one level. It's kinda a pain but it works.
You can also use buildExtensionTemplate
's third argument to add custom args.
this.state.nextMessageIndex = 0; | ||
} | ||
|
||
this.initializeMessageRotation(); |
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.
Lets move this to
onUpdate
and onMount
We should have cleanups on onRender
in addition to onDestroy
See https://github.com/eBay/ebayui-core/blob/master/src/components/ebay-listbox-button/component.ts#L79-L95
(It might not be needed, but I think its good practice in case the parent rerenders or such)
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.
Can you explain this a little more? We only need to re-initialize the message rotation when the messages input is set/changed, so it seems like onInput
would be the right place for this. onUpdate
and onRender
get called frequently for this component, since CSS classes and text content change based on state.
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 it's very close. After this pass it should be good to go.
export const MediumSize = buildExtensionTemplate( | ||
MediumTextTemplate, | ||
MediumTextTemplateCode, | ||
); | ||
MediumSize.args = { | ||
size: "medium", | ||
messages: exampleMessages, | ||
}; |
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 we need this example. We have toggles for toggling medium/large. As long as we spread the input to the other stories we don't need to have this.
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.
Size doesn't just control the text size but also whether the message immediately appears - medium text messages appear immediately, while large text messages animates in after a short delay. Was thinking it would be useful to have a story to highlight this behavior. To your point, though, this behavior can also be seen when toggling the size in the Storybook controls. Just wondering if that might get missed unless people go digging for it.
src/components/ebay-progress-bar-expressive/examples/default.marko
Outdated
Show resolved
Hide resolved
$ const currentMessage = messages[state.currentMessageIndex]?.text; | ||
$ const nextMessage = messages[state.nextMessageIndex]?.text; |
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.
Can we maybe use render body here instead of text?
So have the user do
<ebay-progress-bar-expressive>
<@message>My message</@message>
<@message>My message 2</@message>
</ebay-progress-bar-expressive>
And then in the code we can do
$ const currentMessage = messages[state.currentMessageIndex]?.renderBody
messages[state.nextMessageIndex]?.renderBody
<!-- Later in the code -->
<${currentMessage}>
This is done so we can be flexible in the future in case design changes or there are other requirements.
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 something I was wondering about! renderBody
is definitely more flexible than a text
string, but I also worry it could be misused -- people throwing links and icons in there, etc. But we can draw that line in our design system docs and not necessarily in the code.
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.
Yes that is an issue, but it does provide much more flexibility, especially if design changes to want to include other things in the messages. Im not saying that will happen, but we have seen that in the past.
That said, I agree that if we document what can go in there in our design system docs or even in our documentation here (like storybook description for @messages
), it should be good enough.
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.
Updated to use renderBody in latest commit
609bc89
to
40f354c
Compare
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.
LGTM overall. Just need some minor changes in marko.json then it should be good to go
One additional question: do we need any events? Would emitting an event whenever a message changes be good to have? Or would there not be a reason to.
I think its probably fine to go as is without any events, but just wondering your thoughts.
"targetProperty": null, | ||
"type": "expression" | ||
}, | ||
"@text": "string", |
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.
Lets remove this.
Unfortunately for marko 4 apps, we need to keep this file in sync with our storybook attributes otherwise it won't work properly.
… snapshots, storybook examples
885c65f
to
d464793
Compare
Thanks for your feedback so far, @agliga! Any thoughts on my question in the PR description about vertical padding for long text? Re:
I can't think of a scenario in which it would be useful for a developer to know exactly which message had just shown, since all the messages convey, in essence "something is happening, please wait," just in different words. @ianmcburnie, @ArtBlue, have you gotten a chance to look at this PR? |
Im going to merge this, if anyone wants to look at it we can take the feedback at a later time and iterate. |
Description
New component for expressive progress bar (aka expressive loader)
Context
Recently added the expressive progress bar to Skin, so this is the eBay UI Core implementation of it.
Note that this relies on https://github.com/eBay/skin/tree/17.3.0, which is not yet released.
Question for reviewers
Would like to get your thoughts on handling long messages. Messages ideally only span one line, but with translations, it's possible some may overflow to two. Currently, we don't account for that; see first screenshot below. In practice, I think this component will most often be centered vertically in a larger container, so it's unlikely the text would get cut off. But for a standalone component, it seems like we should handle this case OOTB. Thoughts on adding another CSS class to Skin, e.g.
progress-bar-expressive--tall
that adds padding when one of the messages is above a certain character count?Current
Adding padding to container
References
#2016
eBay/skin#2162
Videos
Default with Messages
PBE-Default.mov
Medium
PBE-Medium.mov
Reduced Motion
In reduced motion mode, messages display slightly longer than their specified duration
PBE-ReducedMotion.mov
Medium Reduced Motion
PBE-MediumReducedMotion.mov