onClose event trigger 2 times.

[webhasan]

onCloese event trigger 2 times
Following the code, I am getting closed alert two times once before showing the message & another one after closing the message.

        toast.success('Successfully registered!', {
          onClose: () => alert('closed')
        });

Video

[dyabol]

onCloese event trigger 2 times Following the code, I am getting closed alert two times once before showing the message & another one after closing the message.

        toast.success('Successfully registered!', {
          onClose: () => alert('closed')
        });

Video

I think is related with this reactwg/react-18#19
Try disable React.StrictMode, it's not solution, but until someone fix it...

[Djunnni]

Hi there, i also catch 2times event trigger in React 18 but it's not evoke in React 17
codesandbox-react17
codesandbox-react18

[webhasan]

@dyabol thanks
Issue solved after disabling StrictMode

[fkhadra]

Hi there, sorry for the late reply. But it's indeed happening because of the new behavior in dev mode when using react18. The same is happening here #752.

I could add some code to ensure that it runs only one time but I don't want to, it's only something happening in dev mode. I'll try to reach other library maintainers to see how they handle this case

[lfernandez55]

Please keep us posted on your thoughts on a fix. It's true that the problem may only appear in dev mode and with strictmode turned on. But strictmode should be used. So until there's a fix I don't feel comfortable upgrading to Toastify 9.0.2. from Toastify 7.0.3 (The problem doesn't occur when using React 18.1 and Toastify 7.0.3)

[fkhadra]

@lfernandez55 sorry to hear that. I can confirm at 100% that the issue will only appear in development. I've also created a codesanbox react18 + react-toastify v7.0.3 and we can see that the issue is occurring

Honestly, the code to trigger onClose is not rocket science at all. It just call the function when the component unmount.

useEffect(() => {
  return () => {
    if(isFn(props.onClose)) props.onClose()
  }
}, [])

I could try to move this logic outside of react but this would require additional work.

That being said, instead of using onClose or onOpen you can use the new toast.onChange . It works as expected even in strict mode as this does not rely on useEffect

toast.onChange(v => {
  if(v.status === "removed"){
   // run your callback
  }
})

cc @shozib13 @dyabol @Djunnni useful link https://fkhadra.github.io/react-toastify/listen-for-changes/

[lfernandez55]

Oh interesting. I was able to confirm as you did that the problem is present in v7.0.3. However, not in all contexts. I have an application running react18 + react-toastify v7.0.3 + CRA + strictmode and when the first toast is generated this is what appears in the Chrome console:

react_devtools_backend.js:4026 Warning: ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it's running React 17.

Since the onClose only fires once in this context I'm inferring that React is behaving as a 17 version instead of 18.

The larger concern however is why this isn't being seen as a bug worth fixing. Shouldn't your users expect to be able to develop in StrictMode without requiring them to change the code when moving from dev to prod? I suppose I could use the onChange event instead. But that's a kludge.

[fkhadra]

@lfernandez55 I feel your pain. Having a piece of code not acting the same way in dev and prod is a nightmare.

The larger concern however is why this isn't being seen as a bug worth fixing.

It's not that it's not worth fixing. React does not provide any API so far to address this behavior. Having to fix a framework behavior in a library is not always easy, especially in this case where the library code doesn't do too much. You would encounter the same issue in your App if you use useEffect for mount and unmount. In that case, it's visible because it calls a callback.

As a maintainer, this is super frustrating. I really hope that the react team provides an alternative to this in a near future. All I can do now is propose an alternative 😞. If there was an easy fix, I would implement it right away, rest assured.

From the react documentation:

If you want to run an effect and clean it up only once (on mount and unmount), you can pass an empty array ([]) as a second argument.

[lfernandez55]

Thanks for the clarification! For our common sake I hope React gets around to addressing this. It seems odd to me that a bug this big would make it into a release. Don't they have any QA where, say, they invite maintainers of popular code to test things out? This problem would have manifested itself in a simple smoke test. It's not obscure at all. And at least from the perspective of this user it's not a trivial bug. When I was trying to upgrade from Toastify 7 to the current release I spent probably two hours thinking I must have coded something wrong. Finally, at wits end, I posted a question to StackOverflow (https://stackoverflow.com/questions/72429197/how-to-trigger-react-toastify-onclose-only-after-toast-closes) but really I think the React team should have been able to spare me that pain.

[lfernandez55]

Maybe it would be helpful to specify in the Toastify documentation what versions of React each version of Toastify is compatible with? If was trying to resolve a minor incompatibility between React 18 and Toastify 7 (e.g. when using Toastify 7, React 18 issues the console warning I refer to above). But the incompatibilities between React 18 and Toastify 9.0.3 are even more pronounced. Maybe I should try React 17 with Toastify 9.0.3. I can try that experiment. But it would be even better if the docs could steer me in the right direction.

[fkhadra]

Ag-grid people raised the same issue facebook/react#24553. They also proposed a workaround I'll see how I can use it in my case https://blog.ag-grid.com/avoiding-react-18-double-mount/

[D-Andreev]

I saw this behaviour today, I understand this is happening because of React 18 rending components twice initially on dev mode.

I tried using onChange instead of onClose as I'm seeing that it's deprecated. However I don't really like the onChange API. As described in the docs, I would have to subscribe to this event, do some kind of if or switch inside to check if this is the correct toast and status removed and perform my actions based on this. After that I need to unsubscribe from onChange.

It's much simpler to just have an onClose handler for the particular toast. What do you think of bringing back onClose and onOpen and making a fix for this? The changes shouldn't be that big right? I can investigate and possibly make a PR if this approach is accepted.

@fkhadra thoughts?

[fkhadra]

Hey the v10, I'm currently working on will address this issue