refactor: extract tag component#742
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
…component # Conflicts: # app/components/Filter/Panel.vue # app/components/Package/Card.vue # app/components/Package/TableRow.vue
Co-authored-by: Daniel Roe <daniel@roe.dev>
| 'bg-fg text-bg border-fg hover:(text-text-bg/50)': status === 'active', | ||
| 'opacity-50 cursor-not-allowed': disabled, | ||
| }" | ||
| :disabled="disabled" |
There was a problem hiding this comment.
@essenmitsosse In HTML the disabled attribute is a boolean attribute and it applies when it is present. I’m seeing it appear in the keyword lists as <a href=wherever disabled=false>. It’s not a huge issue in this case since it has no effect on <a> elements (i.e. disabled isn’t mapped to anything ARIA-related for anchor elements, see: https://www.w3.org/TR/html-aam-1.0/#att-disabled), but if the element did support the mapping then it would always be disabled. Also, worth noting that for the role=radio case, we’d need to manually map aria-disabled ourselves (as an ARIA boolean attribute which does use the "true" and "false" values).
There was a problem hiding this comment.
Thanks for the comments. Will take then into account for the next PR. But also feel confident that it is good not to rebuild UI Elements from scratch every time.
There was a problem hiding this comment.
But also feel confident that it is good not to rebuild UI Elements from scratch every time.
I’m also totally for not needing to rebuild things. What I find though is that it’s really easy to identify and create presentational abstractions (i.e. in this case the class names that produce a tag visually), but how presentational abstractions get applied to elements with various semantics is much harder.
I think we’ll likely need some kind of protocol for what components can be used with the as prop. For example, if we had a primitive <Link> component which could build on <NuxtLink>, but knows that if the disabled prop is passed to it to use aria-disabled, then that could solve the issue without turning stuff like TagClickable into a monster component that needs to know how to handle every case. It can just focus on how to apply presentation to the more primitive UI components that we’ve defined.
There was a problem hiding this comment.
That's more or less what I wanted to sketch out. I think having specific components for their style + semantic combination is the most reasonable way to go.
Co-authored-by: Daniel Roe <daniel@roe.dev>
3 participants
This removes the Uno shortcut
tagand replaces it was a reusable tag component. It adds two version: a static version and a clickable one. The static one is used in two places and I think both of them would be clickable eventually, but I didn't want to make too many decisions in one PR. For now this surfaces all the places where we use a non-clickable tag and changes the styling accordingly (previously those also inherited a hover effect).It also syncs some minor design differences between tags, as well:
disabledstyling (inherited from the only disabled tag we used so far)activestyling (inherited from the only tag that had such so far)This should also make sure all tags have proper focus styles.