[feature]: Toasts

[sirugh]

TODO LIST

• CSS Transitions for toast addition and removal Decided that pop-in/out was fine.
• Refactor error notification work from fix(ux): Add backstop reducer and UI for unhandled errors. Fixes #735 #871 to use toasts.
• If identical toast is repeated reset timeout and flash the opacity to indicate reset
• Dismissable toasts should also auto remove after 7 seconds
• Show online/offline indicator along with online/offline toast.
• Add a warning type (yellow?) toast.
• export from peregrine properly
• Cleanup (console logs, etc)
• Tests
• Handle desktop toasts (currently always centered) cc @soumya-ashok

Description

This PR brings you 🥁 🥁 🥁 🥁 🥁 🥁 toasts 🍞 !

Big changes:

1. Addition of a toast context/store along with hooks that enable usage of the store
2. Implementation of a "toast container" and toasts in Venia (html/css/etc)
3. Refactoring of error notifications to use toasts.
4. Refactoring of online indicator to use toasts.
5. Refactoring of online indicator to live in the header as just an offline icon (when offline).

Toasts should:

• Look delicious.
• Be removable by timeout, or some default (5 seconds).
• Have different states (info, error, etc)
• Be tested!

Related Issue

Closes #783.

Verification Steps

1. Open the app. Enable offline mode in dev tools. See offline toast and icon in header!
2. Disable offline mode. See online toast!
3. Add an error to miniCart.js and rerender. See an error toast!

How Have YOU Tested this?

Manually, and with verification steps, and wrote unit tests.

Proposed Labels for Change Type/Package

• major (e.g x.0.0 - a breaking change)
• minor (e.g 0.x.0 - a backwards compatible addition)
• patch (e.g 0.0.x - a bug fix)

Checklist:

• I have updated the documentation accordingly, if necessary. paging @jcalcaben! Should we make changes to docs for toasts?
• I have added tests to cover my changes, if necessary.

[vercel]

This pull request is automatically deployed with Now.
To access deployments, click Details below or on the icon next to each push.

Latest deployment for this branch: https://venia-git-feature-toasts.magento-research1.now.sh

[jimbo]

@sirugh This looks much better. There are still some rough edges, but this is a big improvement over what we have. A few questions & concerns I still have:

• Is it possible to add a user-dismissable toast that doesn't get auto-dismissed? If timeout is 0 or falsy at all, it should probably not set a timeout, right?
• If a toast has a timeout, and a user tries to copy some text from it to their clipboard, won't the toast often disappear before they can do so? In most apps, I think a toast's timeout is cleared when the user interacts with that toast at all.
• The icon prop of toasts is too tightly coupled to our visual presentation of toasts, I think. I'd prefer to use the type enum to determine what icons to render; if end users want to change the presentation, they'll override the Toast component or use a hook version of it from Peregrine. As is, icon would effectively be a render prop, which we're avoiding. Also, we probably don't want to store functions in state, even if this isn't Redux.

[sirugh]

Is it possible to add a user-dismissable toast that doesn't get auto-dismissed? If timeout is 0 or falsy at all, it should probably not set a timeout, right?

@soumya-ashok and I discussed this, though not sure if we documented it anywhere. Basically all toasts should auto-dismiss for now and the answer for user-dismissable toasts would be to set some long timeout. I can add a workaround to this that does not set the timeout if timeout === 0, but I don't think dismissable: true should have any bearing on auto-dismissal.

If a toast has a timeout, and a user tries to copy some text from it to their clipboard, won't the toast often disappear before they can do so? In most apps, I think a toast's timeout is cleared when the user interacts with that toast at all.

This is a good point. We would need some mechanic to pause the timeout. react-toast-notifications does this and we could too. If you feel strongly about this I can do some work to get this functionality in, otherwise I would say that we hardcode some longer timeout values into the emissions of toasts we expect users to want to copy and then reduce them later. If we chose this option I will create an issue for pausing the timeout. Let me know.

The icon prop of toasts is too tightly coupled to our visual presentation of toasts, I think. I'd prefer to use the type enum to determine what icons to render; if end users want to change the presentation, they'll override the Toast component or use a hook version of it from Peregrine. As is, icon would effectively be a render prop, which we're avoiding. Also, we probably don't want to store functions in state, even if this isn't Redux.

The way we create/use icons in our application is that we have the component who needs it import/use it. We can't know all the different icons that toast emitters want to put into their implementations, so we allow them to pass the whole icon. This is definitely a tight coupling to the display, but intentionally so that the display doesn't have to import every possible icon. We could have the toast component enumerate a subset of icons and basically ask anyone who reimplements Toasts to provide an icon enums as well. Again, we can talk about this before I make changes.

[jimbo]

I can add a workaround to this that does not set the timeout if timeout === 0, but I don't think dismissable: true should have any bearing on auto-dismissal.

I like this approach.

I would say that we hardcode some longer timeout values into the emissions of toasts we expect users to want to copy and then reduce them later. If we chose this option I will create an issue for pausing the timeout.

I also like this approach.

We could have the toast component enumerate a subset of icons and basically ask anyone who reimplements Toasts to provide an icon enums as well.

This is exactly what I'd like to do. We already have the enum with type, and the icon should be a reflection of type. More complicated functionality should be left to the re-implementation, I think. Thoughts?

[sirugh]

This is exactly what I'd like to do. We already have the enum with type, and the icon should be a reflection of type. More complicated functionality should be left to the re-implementation, I think. Thoughts?

Can you point me at the type you are talking about?

[jimbo]

Can you point me at the type you are talking about?

Here.

type
info
warning
error

[sirugh]

Oh so the type of the toast does not indicate the icon, unfortunately. Anyone could emit a sad face icon with an error toast to indicate some error or a cloud-off icon with an error toast to indicate offline.

[sirugh]

Created #1284 for timeout pausing.

[jimbo]

@sirugh Thanks for making changes. I've updated the prop types of Toast. Ready to merge it?