-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Fix type errors for Button's use of Icon data. #125
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
--- | ||
'svelte-ux': patch | ||
--- | ||
|
||
Added new `IconInput` and `IconData` types to enable inclusive & seamless passing of icon arguments between components. Also provides a `asIconData` utility function for type-safe conversion. | ||
Fixed type errors for Button & TextField's use of Icon data. | ||
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,17 @@ | ||
|
||
import type { ComponentProps } from "svelte"; | ||
import type { default as Icon } from "$lib/components/Icon.svelte"; | ||
import { isLiteralObject } from "./object"; | ||
|
||
export type IconInput = ComponentProps<Icon>['data'] | ComponentProps<Icon>; | ||
export type IconData = ComponentProps<Icon>['data']; | ||
|
||
export function asIconData(v: IconInput): IconData { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if we call this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I considered that initially, and I'm good with that if you prefer it. Only reason I chose There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can leave it |
||
return isIconComponentProps(v) ? v.data : v; | ||
} | ||
|
||
function isIconComponentProps(v: any): v is ComponentProps<Icon> { | ||
// `iconName` is a required property of `IconDefinition`, the only other object that `IconInput` supports. | ||
// If it is undefined, then only ComponentProps<Icon> is viable. | ||
return isLiteralObject(v) && typeof(v['iconName']) === "undefined"; | ||
} |
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.
<Icon>
used to just accept<Icon path="...">
...then it was extended to allow
<Icon svg="...">
, ```...then it was extended to have a simple
<Icon data="...">
prop and infer which of the props was intended (path, svg, svgUrl), so I call that a feature to allowTextField
to take in more options than justpath
:).svgUrl
is quite useful when your loading over the network, and not populating your bundle with all potential options.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.
Hehe, I wasn't saying that it doesn't support different kinds of inputs. More that, we have instances of wrappers with inner wrappers with inner-inner Icons, etc. and the allowed data types for those wrapper components' distinct arguments do not always match, leading to inconsistency that has the potential to force type errors for no reason. I actually have to compliment this project for the diversity of data formats that
Icon
supports.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.
:). It's been battled tested in a lot of use cases. One thing I struggle with is getting the time to show all the niceties in examples :).
<Table>
is under represented for how much it packs ;)