-
Notifications
You must be signed in to change notification settings - Fork 4
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(filter-pill): DLT-1917 create component #473
base: staging
Are you sure you want to change the base?
Conversation
Please add either the |
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.
Great start! Functionality, props, and slots are as I expected. The design very likely will change the raw html/css.
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.
Approved at least in current designed state. Defer to others for technical review.
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.
Looks pretty great so far, will review more tomorrow morning.
class="d-filter-pill" | ||
data-qa="dt-filter-pill" | ||
:open="isPopoverOpen" | ||
@update:open="isPopoverOpen = $event" |
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.
Shouldn't we just use v-model / sync if we're going to do 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.
Also should this component support v-model / sync?
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.
Also should this component support v-model / sync?
Didn't found any use-case on product that had the filter previously opened, or do you mean for something like the "active" state?
packages/dialtone-css/lib/build/less/components/filter-pill.less
Outdated
Show resolved
Hide resolved
packages/dialtone-css/lib/build/less/components/filter-pill.less
Outdated
Show resolved
Hide resolved
packages/dialtone-css/lib/build/less/components/filter-pill.less
Outdated
Show resolved
Hide resolved
packages/dialtone-css/lib/build/less/components/filter-pill.less
Outdated
Show resolved
Hide resolved
packages/dialtone-css/lib/build/less/components/filter-pill.less
Outdated
Show resolved
Hide resolved
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.
Thanks, couple more comments from this morning. I screen reader tested as well, looks good!
/** | ||
* Determines if the filter is loading | ||
*/ | ||
loading: { | ||
type: Boolean, | ||
default: false, | ||
}, |
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.
Hmm not sure about this loading implementation. Why did we use a skeleton instead of the built in "loading" prop on button that shows a spinner? This looks a bit strange:
There was also no loading prop requirement in the ticket https://dialpad.atlassian.net/browse/DLT-1917. Not to say it won't be useful at some point, but I didn't find any existing implementations of filter pill that show a loading indicator within the button.
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't find the button I saw using that, but I copied the functionality from there.
Makes sense to use the loading prop of the button as we don't want to keep introducing new loaders.
It made sense for me as there was actually going to be text there, but I'll change it to the loading
prop, it's going to be easier to maintain.
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.
Actually, the loading
prop of the button replaces the entire button content. I'd prefer to maintain the loading skeleton in that case.
@francisrupert can you help us to decide here please?
loadingSkeletonWidth: { | ||
type: String, | ||
default: '128px', | ||
}, |
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.
Changing this changes the entire width of the button rather than the width of the skeleton. Intended?
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.
As the skeleton is growing/shrinking it'd be expected that the button size change, right? The use-case I saw for this was setting the loading-skeleton-width to the actual text-size which could be calculated either on the client or I can add that here but I'd be more flexible if I left the client to decide the width of the loading skeleton.
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.
If the client is receiving the text from a server it won't know its size until the request is complete in which case it is done loading. Calculating width based on the length of a string even if we had it is VERY difficult due to variable width fonts, i18n, and text scaling. Basically the same problem we had in this ticket where we were trying to dynamically change the size of the field based on the language and it was impossible to size it correctly.
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.
Ok, setting it to the text size was too ambitious 😅 but having the flexibility to change the size is ok, right?
<template> | ||
<dt-popover | ||
class="d-filter-pill" | ||
data-qa="dt-filter-pill" |
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 probably want to pass through "placement" and "fallbackPlacements" prop since they're very commonly used.
placement can default to "bottom-start"
fallbackPlacements can default to ["top-start", "auto"]
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.
A couple other props I think we'll need to pass through
appendTo
maxHeight
maxWidth
padding
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.
Makes sense, I wasn't thinking on those, thanks!
<dt-button | ||
v-if="showReset" | ||
data-qa="dt-filter-pill__reset-button" | ||
class="d-filter-pill__reset" | ||
circle | ||
importance="clear" | ||
kind="muted" | ||
:size="size" | ||
:aria-label="resetButtonAriaLabel" | ||
@click="$emit('reset', $event)" | ||
> | ||
<template #icon="{ iconSize }"> | ||
<dt-icon-close :size="iconSize" /> | ||
</template> | ||
</dt-button> |
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 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 button is the same size as the other button, should be ok. What they're doing on product is only changing the "X" icon color but not changing the background color on hover. I can do the same here but I wanted to keep the button implementation.
I thinks this might change with the upcoming @francisrupert updates
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.
Preview of WIP Design, via Draft PR #484.
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 I should wait until you have the final HTML implementation so I can make the appropriate changes here.
Maybe closing this PR and open a new one with the final implementation, what do you think? @francisrupert @braddialpad
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.
sure, or you can just PR a new PR into this branch. I don't think there's really any reason to release this early.
# Conflicts: # packages/dialtone-css/lib/build/less/dialtone.less
✔️ Deploy previews ready! |
Add DtFilterPill component
Obligatory GIF (super important!)
🛠️ Type Of Change
These types will increment the version number on release:
📖 Jira Ticket
https://dialpad.atlassian.net/browse/DLT-1917
📖 Description
.eslintignore
paths.💡 Context
This component is still not ready for production, will not be exported until @francisrupert completes the Figma and Design proposal.
📝 Checklist
For all PRs:
For all Vue changes:
./scripts/dialtone-vue-sync.sh
script. Read docs here: Dialtone Vue Sync ScriptFor all CSS changes:
If new component:
packages/dialtone-vue2
orpackages/dialtone-vue3
).packages/dialtone-css
package.apps/dialtone-documentation
.common/components_list.cjs
🔮 Next Steps
📷 Screenshots / GIFs
Sources
Links