-
Notifications
You must be signed in to change notification settings - Fork 5
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
Feature: Button asChild
/ Link asChild
#552
Conversation
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.
Very cool 😎
…extStep in handleClick" This reverts commit 6331a7a.
|
||
const buttonSpecificProps = href ? {} : { type } | ||
if (asChild) { |
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 understand how the loader will work if we are using the asChild option?
Closing this PR while we look into alternative options for improving our polymorphism |
This PR changes how the
Link
andButton
components handle polymorphism. Instead of usingas="a"
/as="button"
internally or externally, we can now useasChild
and render the required element as children. This pattern helps with a bunch of typescript issues and retains the composability of styling and logic that we had previously. We use the RadixSlot
component internally to merge anystyle
,className
,ref
,onClick
props, so we can composeLink
with any child component.I've also added logic for some useful (necessary?) attributes in the
Link
component if thehref
is not relative. This logic is currently handled by our "middleware" design-system components inatom-core
, but they will eventually be removed so I moved it here. We lose the ability to do this with ourButton
components however, as we delegate responsibility for rendering the element to the user, so we can't repeat the same logic inButton
. I think this is an ok compromise as the logic is not complex at all and the number of non-relative href "button"s we render is minimal.There are ~100 instances of
Link
andButton
components that will need to be updated inatom-core
, but it should be a fairly simple migration. I have avoided updatingActionIcon
with this logic as we're looking at deprecating the component soon, but I could look to updateTile
if we like this approach.With this pattern we get nicely merged
css
props, valid types and autocomplete on the child and parent, and composedonClick
methods as expected