enqueueSnackbar multiple times ignores maxSnack about notistack

[AnaBrade]

We have the same issue as tomzaku. It seems that all configurations get ignored when adding snackbar while iterating through an array. I tried to fix the issue by setting preventDuplicate totrue and I still get multiple snackbars with the same message. Can be replicated in tomzaku's sandbox by adding preventDuplicate: true.

[iamhosseindhv]

@Kizmar Thanks for reporting this. I'll investigate this. It'd be nice to have a sandbox reproduction though.

I'll update sandbox link in issue template to this.

[Kizmar]

Sorry for the delay, been scrambling with the holidays coming up. I'll try to get a sandbox reproduction up here in the next day or two.

[iamhosseindhv]

Any update?

[iamhosseindhv]

Closed due to inactivity. feel free to reopen anytime.

[babradshaw]

I have the same issue ... mobx store starts with 4 items which are enqueued during the notifier mount ... all 4 are displayed even though maxSnack=1 on the SnackProvider. I thought it would internally queue the notifications when more are enqueued than the max.

If I have persist on I see this in the console:

Reached maxSnack while all enqueued snackbars have 'persist' flag. Notistack will dismiss the oldest snackbar anyway to allow other ones in the queue to be presented.

[iamhosseindhv]

I'll reopen and investigate this.

[MortezaHeydari97]

Hi, I've the same problem. When I try to show a snackbar, at the first time, it will not declare and at the second time it shows two times.

Can you help me how can I fix this?

[iamhosseindhv]

@MortezaHeydari97 please share the code you have to enqueue snackbar.

[MortezaHeydari97]

@MortezaHeydari97 please share the code you have to enqueue snackbar.

I fixed it, so thanks.

[tomzaku]

I have the same issue, My code sandbox here: https://codesandbox.io/s/notistack-redux-example-gyw9u
How can I solve that

[simonbos]

A minimal example for this bug: https://codesandbox.io/s/notistack-simple-example-xpff1 (click on the default button). Important lines:

  handleClickWithAction = () => {
    this.props.enqueueSnackbar("Customise this snackbar youself.");
    this.props.enqueueSnackbar("Customise this snackbar youself.");
    this.props.enqueueSnackbar("Customise this snackbar youself.");
    this.props.enqueueSnackbar("Customise this snackbar youself.");
  };

The bug appears when the enqueueSnackbar method is called multiple times in one synchronous method, or before the React tree re-renders. I believe the origin of the bug lies in the following code (from SnackbarProvider.js)

    /**
     * Display snack if there's space for it. Otherwise, immediately begin dismissing the
     * oldest message to start showing the new one.
     */
    handleDisplaySnack = () => {
        const { maxSnack } = this.props;
        const { snacks } = this.state;
        if (snacks.length >= maxSnack) {
            return this.handleDismissOldest();
        }
        return this.processQueue();
    };

    /**
     * Display items (notifications) in the queue if there's space for them.
     */
    processQueue = () => {
        if (this.queue.length > 0) {
            const newOne = this.queue.shift();
            this.setState(({ snacks }) => ({
                snacks: [...snacks, newOne],
            }));
        }
    };

When handleDisplaySnack is called, the snacks array is fetched from the state and checked if the length of the array is greater or equal than maxSnack. If not, the state adds a new snack from the queue.

However, the bug appears because setState is asynchronous: at the beginning of the above handleClickWithAction, the length of const { snacks } = this.state; is 0. At the end, after the four enqueueSnackbar invocations it will be still 0, and it will remain that way untill the setState calls are effectively executed. The relevant React docs:

setState() does not always immediately update the component. It may batch or defer the update until later. This makes reading this.state right after calling setState() a potential pitfall.

In my view, a solution for this error would require to handle snacks.length >= maxSnack in the setState reducer, i.e. something like:

this.setState((prevState) => ({
    if (prevState.snacks.length >= maxSnack)
       return handleDimissOldest(prevState)
    return processQueue(prevState)
}));

Any thoughts @iamhosseindhv ?

[iamhosseindhv]

correct @simonbos. The issue originates in asynchronous nature of setState. #15 tried and somewhat managed to solve the issue. If you follow the discussion in that thread you'll find out why it didn't get merged. But I like the general idea in #15 and this issue is on top of my todo list.
Any PR welcome.