Fix #2981: let DEFAULT_TIMEOUT for Toasts be used

[brendanfalkowski]

Description

Toasts don't use the DEFAULT_TIMEOUT which is defined, so developers must specify it in every instance.

Related Issue

Closes #2981.

Acceptance

Verification Stakeholders

Specification

Verification Steps

1. Find an instance of addToast()
2. Remove the timeout prop.
3. It should fallback to the default specified in the hook.

Screenshots / Screen Captures (if appropriate)

Checklist

• I have added tests to cover my changes, if necessary.
• I have added translations for new strings, if necessary.
• I have updated the documentation accordingly, if necessary.

[PWAStudioBot]

	Fails
🚫	A version label is required. A maintainer must add one.

	Messages
📖	DangerCI Failures related to missing labels/description/linked issues/etc will persist until the next push or next nightly build run (assuming they are fixed).
📖	Access a deployed version of this PR here. Make sure to wait for the "pwa-pull-request-deploy" job to complete.

Generated by 🚫 dangerJS against 7c18f92

[sirugh]

I want to say this is working as intended, but I'd happily concede the point if you can show me an example where this is not working properly.

[sirugh]

We specifically did not do this because passing a timeout of 0 or false is allowable, and actually means "do not time out". We actually do use the default timeout later in the file:

pwa-studio/packages/peregrine/lib/Toasts/useToasts.js

Lines 149 to 158 in 9edff92

	// A timeout of 0 means no auto-dismiss.
	let removalTimeoutId;
	if (timeout !== 0 && timeout !== false) {
	removalTimeoutId = setTimeout(
	() => {
	handleDismiss();
	},
	timeout ? timeout : DEFAULT_TIMEOUT
	);
	}

If you pass a timeout of 0 or false, it never times out (meaning the user has to close it manually).
If you pass a timeout of a number > 0, it uses times out after that.
If you do not pass a timeout, it times out after the DEFAULT_TIMEOUT.

[jimbo]

We specifically did not do this because passing a timeout of 0 or false is allowable

Sure, but application of the default param here only happens if props.timeout is undefined. Seems like the right change to make to me, unless I'm missing something else.

[brendanfalkowski]

My DevEx case was not wanting to pass any props that just reiterate what the logic determines to be default behavior. So { message, type } is better than having to remember { message, timeout, type } or { dismissable, message, type } every time.

[sirugh]

Sure, but application of the default param here only happens if props.timeout is undefined.

Huh, for some reason I thought it would not apply but I think I'm confusing defaultProps with destructured defaults.

[jimbo]

We specifically did not do this because passing a timeout of 0 or false is allowable

Sure, but application of the default param here only happens if props.timeout is undefined. Seems like the right change to make to me, unless I'm missing something else.

I'm wrong!