-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Return value of the date knob is unclear #1489
Comments
A further breakdown of my concerns:
I realize that not everyone will have the same experience, but all of the above factors combine in my case to result in the following component call in my story, just to pass a
Yes, this can be broken down further to make it more readable, but it feels like the API is putting a lot of burden on the developer compared with the other knobs. |
(sorry... I keep having thoughts about this) One potential quickish way to improve this would be adding an optional third argument to the
It's not perfect, but it's a start? |
Would love to get a PR for an update to the docs or a potentially better solution. |
I also use ISO8601 strings to represent timestamps in my application, and this is what I came up with: import { date } from '@storybook/addon-knobs'
const defaultDate = new Date('2017-11-17T13:00:00Z')
export function timestamp(name: string, defaultValue?: Date): string {
const value = date(name, defaultValue || defaultDate)
const d = new Date(value)
return d.toISOString()
} Which I use in my components like so: import { timestamp } from 'path/to/my-custom-knobs'
storiesOf("Some component")
.add("timestamp knob", () => (
<SomeComponent timestamp={timestamp('foo')} />
)) It might be nice to extend the knobs addon with completely custom knobs (e.g. with a custom UI as well). Is that possible? |
Document return type of `date` knob (see #1489)
The documentation for the date knob is a bit sparse.
The date knob returns a UNIX timestamp as a string. That's a perfectly fine way to return a date/time, but it's one of many. It's especially confusing, because the knob accepts a
new Date
as input, but returns a string of a UNIX timestamp.I'm happy to send a PR for this, but I wanted to open it up for discussion first, since the discrepancies between input and output seem a bit confusing, even with documentation. A different implementation may be desirable?
The text was updated successfully, but these errors were encountered: