Ability to hook into Snackbar messaging

[mattcorner]

Feature Request

Describe the problem related to this feature request

I'm beginning to wonder if it would be better for me to able to hook in directly to the snackbar messages, and use my own components rather than relying on the the included snackbar.

Some issues that this would solve:

• Snackbars drawing over each other.
• Full control over what types, or even messages to show.
• Full control over styling that theme override may not be able to provide.

Describe the solution you'd like

Expose a new prop. Something along the lines of
<Dropzone onMessage ={ (message, variant) => {//Do what I want}} />
Could be called in a useEffect with message and variant dependencies.

Describe alternatives you've considered

The alternative is to stick with the current system, but this will always be restrictive when the user wants full control. This proposal gives advanced users the information needed, without having to overly complicate the snackbar offering.

[max-carroll]

In the hooks functional component refactor I'm working on I am extracting some of this logic out, I will think how I can do this in such away that would make it amenable to be extended to this in the future. I was thinking about having a sendInfoMessage, sendErrorMessage, send...Message functions exposed from a hook, so perhaps they could be overridden, or perhaps i should just use sendMessage(message, variant) perhaps that makes more sense. Then these could be overridden by passing in props, or defaulting to the hooks method if not passed in perhaps? Will have a think about this.

…

On Fri, 12 Jun 2020 at 03:22, Matthew Corner ***@***.***> wrote: Feature Request Describe the problem related to this feature request I'm beginning to wonder if it would be better for me to able to hook in directly to the snackbar messages, and use my own components rather than relying on the the included snackbar. Some issues that this would solve: - Snackbars drawing over each other. - Full control over what types, or even messages to show. - Full control over styling that theme override may not be able to provide. Describe the solution you'd like Expose a new prop. Something along the lines of <Dropzone onMessage ={ (message, variant) => {//Do what I want}} /> Could be called in a useEffect with message and variant dependencies. Describe alternatives you've considered The alternative is to stick with the current system, but this will always be restrictive when the user wants full control. This proposal gives advanced users the information needed, without having to overly complicate the snackbar offering. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#200>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHC7Y5AX22U7D2S3X7SCMLRWGGPDANCNFSM4N35TMMA> .

[panz3r]

Hi @mattcorner,

Thanks for your feedback, I came to the same conclusion some time ago (in one of my projects I disabled the integrated Snackbar to use Notistack instead).

I suppose we can add the ‘onMessage’ handler side-by-side with the current behavior so a user can react to the message events and, if he needs to, turn off the integrated Snackbar (by setting the showAlert prop).

This way we can avoid a major breaking change and quickly implement this new behavior you are suggesting.

[mattcorner]

I was thinking about having a sendInfoMessage, sendErrorMessage,
send...Message functions exposed from a hook,

I don't really mind but from an api point of view it seems nice to to only expose one prop for this. I've implemented Context/Provider/Hook for snackbars in several projects and found one show (and hide) method on the hook to work well.

I suppose we can add the ‘onMessage’ handler side-by-side with the current behavior so a user can react to the message events and, if he needs to, turn off the integrated Snackbar (by setting the showAlert prop).

I had a quick flick through the code before raising, and it seems the messages are set in state regardless of whether snackbar is enabled so shouldn't be much hassle like you say. Just need to agree on an api that isn't going to change in 4.0 with the siwtch to hooks.

[mattcorner]

p.s. Happy to support with any code/ pull request reviews on this if helpful.

[panz3r]

I don't really mind but from an api point of view it seems nice to to only expose one prop for this. I've implemented Context/Provider/Hook for snackbars in several projects and found one show (and hide) method on the hook to work well.

I totally agree on this 👍

I suppose we can add the ‘onMessage’ handler side-by-side with the current behavior so a user can react to the message events and, if he needs to, turn off the integrated Snackbar (by setting the showAlert prop).

I had a quick flick through the code before raising, and it seems the messages are set in state regardless of whether snackbar is enabled so shouldn't be much hassle like you say. Just need to agree on an api that isn't going to change in 4.0 with the siwtch to hooks.

To keep it in line with the current “module dictionary” I’d say that the new method should be called onAlert (since we refer to the Snackbar using that name).

[mattcorner]

onAlert

Sounds good to me. So we're looking at something like this in terms of doc:

PropName: onAlert
Type: func
Default: undefined
Description: Arguments

• message: String - Alert message describing event that has occurred.
• variant: Enum["info", "error", "success"] - Type of alert that has occurred.

In terms of functionality:

• Should be available regardless of the showAlerts property value.

[panz3r]

Hi @mattcorner ,

That looks great, would you like to try implementing it?