Notistack: Props from enqueueSnackbar are not forwarded to custom snackbar component

[IsenrichO]

Summary

• When using notistack with a custom snackbar (via the content prop on the SnackbarProvider), config props passed to enqueueSnackbar are not forwarded. For example, when doing something like

enqueueSnackbar('This is my custom snack!', {
  variant: 'error',
  autoHideDuration: 6000,
});

the custom snackbar component provided to SnackbarProvider does not receive any part of the config object (variant, autoHideDuration, etc.).

• Likewise, using the top-level action prop on SnackbarProvider does not pass along the action to all custom Snackbar instances.

Expected Behavior

The options object passed to enqueueSnackbar should be passed to the invocation of the custom Snackbar component.

Current Behavior

The custom Snackbar component does not receive any part of the options object.

Steps to Reproduce

Link: https://codesandbox.io/s/elated-browser-0ck73

1. Click the "Trigger Snack" button in the example.
2. Check the console in the CodeSandbox and see how the action and variant props are undefined even though enqueueSnackbar was called with those props.

Context

Notistack is an awesome tool and something I'd like to leverage instead of far more verbose alternatives. I'm just finding certain gaps when it comes to using Notistack with custom snackbar components and trying to help fill those holes.

From a brief look at the code, I would wager a guess that the problem lies in these few lines where snackContent doesn't seem to pass through props from the Provider.

Your Environment

| Tech | Version |
|--------------|---------|
| Notistack | v0.9.7 |
| React | v16.12.0 |
| Browser | Chrome latest |

[iamhosseindhv]

This is intentional. If you wish to use props that is passed to SnackbarItem or material-ui Snackbar component, there is support to customise appearance of snackbars through for example classes prop.

content prop is intended to display something entirely different, similar to the example we have on the documentation website.

If you think this is not reasonable, please give more details regarding what you're trying to achieve.

Likewise, using the top-level action prop on SnackbarProvider does not pass along the action to all custom Snackbar instances.

I have no idea how notistack can inject a component into your custom component. PRs welcome.

[IsenrichO]

This is intentional. If you wish to use props that is passed to SnackbarItem or material-ui Snackbar component, there is support to customise appearance of snackbars through for example classes prop.

content prop is intended to display something entirely different, similar to the example we have on the documentation website.

Yes, I don't need just different styling. I'm intentionally using a custom snackbar.

If you think this is not reasonable, please give more details regarding what you're trying to achieve.

I don't agree with the reasoning because I think it makes the enqueueSnackbar api inconsistent. To illustrate by example, we can simply compare how we would dispatch a new snackbar with and without a custom Snackbar.

Without custom snackbar:

enqueueSnackbar('This is my normal snackbar', { variant: 'warning' });

vs. With custom snackbar

// Provider.tsx
<SnackbarProvider
  // Hackily spread `message` param since I have to use it as an object to give custom snackbar access to options
  content={(key, message) => <Snackbar snackKey={key} {...message} />}
/>

// some other component
enqueueSnackbar({
  message: 'Hacky way of getting options to custom snackbar',
  variant: 'warning',
});

So while I need custom snackbar, I would still like to be able to leverage the existing enqueueSnackbar because my custom snackbar still has variable behavior depending on things like the variant. As you can see, I'm having to rely on hacks in order to be able to actually get the variant (and other snackbar options) to the custom snackbar at all.

If you're at least open to supporting this, I can try my hand at a PR.

[pixel-shock]

👍 here, cause the "custom snackbar item" makes no sense at all without every prop passed through the enqueueSnackbar function.

[iamhosseindhv]

@IsenrichO sorry I missed your reply.

Can you think of cases where you need a prop from enqueueSnackbar other than variant?

It makes complete sense to pass key, message and variant to custom component. Currently we only pass key and message.

Open to discuss and PR this. @pixel-shock

[IsenrichO]

@iamhosseindhv I think @pixel-shock said it best... every prop should be passed through. If enqueueSnackbar is given an options object, one would expect the entire object to be forwarded to the custom snackbar.

Can you think of cases where you need a prop from enqueueSnackbar other than variant?

Yes, many of them. We encounter lots of one-off cases that call for something other than the default "Dismiss" action, so I'd definitely like to be able to make use of that. Likewise, it'd be nice to have access to the onClose callback. And then there are more application-specific things that we pass around like data-e2e tags for E2E testing purposes. For this reason, I think it's best not to discriminate and simply always forward the options object to the custom snack; what we choose to do with the forwarded props is our problem then.

If it helps, here is a screenshot illustrating what my custom snackbar looks like for the error variant.

[pixel-shock]

I think @IsenrichO explained it properly. 👍
Just think about to use "notisnack" just as a "wrapper" to handle the whole logic besides the content of the snackbar.
If you want to customize the SnackbarItems completely like custom action callouts for each custom item, not for the whole snackbar. E.g. Undo Action, Redo Action, Dismiss Action etc.
Or in my case I have kind of a callback for the SnackbarItem which is called on close to delete some stuff out of the MongoDB. The callback is saved into the state of the SnackbarItem and if the user clicks "undo" or "cancel", then the callback is removed from the state and the SnackbarIem will just dismiss without doing anything.

[pavelspichonak]

@iamhosseindhv I understand what @pixel-shock and @IsenrichO mean and what they want. Also I understand what you mean saying

Can you think of cases where you need a prop from enqueueSnackbar other than variant?

Indeed all you need to pass(and you do not pass now) is variant. All other props are handled by snackbar component from material-ui.

If you pass all options down, in this case users need to handle closing snackbar items by themself(now it is done by snackbar and maybe collapse components).

Could you please pass now variant? It looks like it is so small change but so necessary.

[iamhosseindhv]

@pavelspichonak I'm working on passing all options including variant. You can track the progress here: https://github.com/iamhosseindhv/notistack/issues/242

[ChristmasWoe]

I've met the same problem doing my custom notifications and have come up with own solution:
You can use JSON.stringify method(https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) and JSON.parse (https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse) to create options object and turn it into string, pass this string as message and then parse it in your custom component (or right in index.js).
In component, where I call notistack
let options = { type: 'large', variant: 'success', message: 'Your message has been saved', header: 'Drafts', } this.props.enqueueSnackbar(JSON.stringify(options), { variant: 'success', });
Index.js

const formOptions = optionsString => {
  if (optionsString == undefined) return {};
  let options = JSON.parse(optionsString);
  return options
}

ReactDOM.render(
  <SnackbarProvider maxSnack={3}
    content={(key, message) => (
      <MyComponent id={key} options={formOptions(message)} />
    )}

  >
<App />
</SnackbarProvider >

then access options directly from props in your component

[Bdthomson]

@ChristmasWoe Thanks, we ended up doing just that. While a bit hacky, it gets the job done!