Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Drawer] Switching between open "normal" drawer and closed modal drawer creates odd effect #1004

Open
dawsonc623 opened this issue Sep 29, 2019 · 0 comments

Comments

@dawsonc623
Copy link

https://codesandbox.io/s/lucid-hill-1t9dv

So, the operation of the demo is a little weird, but it was the simplest example I could come up with. If you click "Switch to modal", click the menu button in the top app bar, click "Switch to normal", and then click "Switch to modal" again you will see what I am talking about when I say "odd effect". The close animation still plays even when the "close" is triggered before switching to "modal".

The effect I am looking for is that when switching from normal to modal, the modal will always be closed, even if it was opened prior to switching from modal to normal. In my code, this is actually triggered by a window resize event - when the document body's width goes below a certain threshold, the navigation switches from the normal, always present version to the modal version triggered by the menu button in the top app bar.

At first, I thought it had to do with React batching state changes (so the close and modal switch occurred simultaneously), so on line 67 I also tried to apply a setTimeout to trigger the modal switch on the next render cycle. That actually caused the modal to not close on the modal switch at all. It might be worth noting that since state changes are not batched in native event handlers, my actual code presents with the second case.

After diving into the drawer's source code, I do understand why the code behaves that way. However, I am not sure if this would be considered an issue with the drawer code, or if there needs to be some workaround implemented on my end. If it is the former, if we can work out a clear definition of intended effect in this case I can try to work on a PR for it. If it is the latter, nothing I have tried has worked in my case (mostly changing the order of the events to circumvent the issue), so I would greatly appreciate any ideas to try.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant