updated toast sometimes has wrong styles
See original GitHub issueDo you want to request a feature or report a bug?
bug
What is the current behavior?
when a toast is updated immediately, it is sometimes missing the correct classname. in the codesandbox example below, when the toast is updated to “success” type, it sometimes (the first time?) has “default” styling.
note that when the toast update is wrapped in setTimeout(..., 0)
it seems to work fine.
also note, that this looks like a regression in version 8.2, in version 8.1.1 the toast updated correctly.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn’t have dependencies other than React. Paste the link to your CodeSandbox (https://codesandbox.io/s/new) example below:
https://codesandbox.io/s/boring-rain-x5ckbw?file=/src/App.js
What is the expected behavior?
toast should show correct styles for type when updated
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:9 (2 by maintainers)
Top GitHub Comments
@cpecorari can you try the latest major release. It’s still in RC but pretty stable if you want to give it a try.
npm installl react-toastify@next
You can find the release note here https://fkhadra.github.io/react-toastify/migration-v9
Some additional information. I tried downgrading to 8.1.0 as @stefanprobst suggested, and the toast update issue went away. So there was definitely a change introduced at some point that caused this bug, in case that helps @fkhadra .
Also, something I noticed is the bug only happens consistently when I try to update notifications approximately less than 1 second. So for example, the following gets the styling bug (content updates correctly, type remains as “info” and doesn’t update to “success”)
HOWEVER, the moment I increased the timeout into something into the 750-1000ms range, the bug went away. It’s really strange, and it’s the only thing I can think out as far as repro information for the bug. Sorry I can’t link a Codepen or CodeSandbox.