-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Toast docs + children support #2048
Conversation
Question:Should (my gut is |
Toast docs: clarify usagePreview: documentation | landing | table |
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.
toasts don't work in the docs preview
aligned along the top or bottom edge of its container (new toasts will slide in from that edge) and | ||
horizontally aligned along the left edge, center, or right edge of its container. | ||
Render the `<Toaster>` component like any other element. Then, either access the instance methods by supplying | ||
a `ref` handler (see example below), or supply rendered `<Toast>` elements as `children` of the `<Toaster>`. |
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'm not sure why we're suggesting a ref
handler... if someone really wanted to do this in a React-idiomatic way, wouldn't they provide toasts as children
? What are the benefits of this over the Toaster.create()
API? I feel all these options make the usage docs more confusing.
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'll move the children
suggestion first and note that you can ref
but please don't (see next paragraph).
@@ -58,51 +51,71 @@ OurToaster.update(key, { message: "Still toasted!" }); | |||
enable `autoFocus` for a `Toaster` via a prop, if desired. | |||
</div> | |||
|
|||
@### Static method | |||
@interface IToaster |
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 this should go inside the "Static usage" section, after the first bit of prose there. Prefer reading prose first, detailed props tables later
Overlay supports falsy childrenPreview: documentation | landing | table |
f9a9ef9
to
2ab94e8
Compare
docsPreview: documentation | landing | table |
`Toaster` can be used in one of two ways: | ||
|
||
1. `Toaster.create(props)` static method returns a new `IToaster` instance. Use the instance method `toaster.show()` to manipulate this instance. __(recommended)__ | ||
1. Render a `<Toaster>` element and either use the `ref` prop to access its instance methods, or pass rendered `<Toast>`s as `children`. |
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.
This feels like 3 options.
Toaster.create(...)
<Toaster ref={...} />
<Toaster><Toast ... /></Toaster>
they can all be mixed & matched anyway, so might as well list all 3.
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.
2 and 3 can be mixed, no way to provide
children to 1.
but yes there are three, so i'll update
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.
well you can combine option 1 with 2 & 3, you'd just get multiple Toaster instances
three ways to use a toasterPreview: documentation | landing | table |
Love it, thanks for following through! |
Fixes #1224
Changes proposed in this pull request:
Toaster
renderschildren
after state toastsOverlay
now passes through non-JSXchildren
string | number
children will not be animated. to be fair, this is an improvement over the previous behavior where it would simply die if given non-JSX children.