-
Notifications
You must be signed in to change notification settings - Fork 917
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
%JS{} based transitions block all interaction with LiveView instances until the transition has finished #3101
Comments
No this is by design. Transitions should in general be 300ms or less and defaults to 200ms. They are for polished UI transitions and anything beyond that introduces latency. We necessarily have to lock the DOM during a transition, so if you need longer, it's on your own css rules/js to make it happen. Thanks! |
If I understand it correctly, this locking seems like the culprit behind the following two types of issues:
As suggested in the #3139, I have proven this relation b/w using I don't want to jump into conclusions, but if the locking itself (and not some bug related to it) indeed proves to be the reason behind this, then it would be correct to state so in the docs, for what it would essentially comes down to is that
If that's the case and given that in the app I am developing all of the above apply, I will need to replace the use of all In addition, it will be of great help knowing if there are other situations (besides transitions) where you lock the DOM. Thanks |
fyi: there’s a |
Thanks, will consider it once LV1.0 final is out. For the time being I'm sticking to 0.20.17 |
This is not a bug, but I'd say it's an undesired behavior especially when it comes to having more than just one LiveView instance - or does the limitation only apply to the nested instances and not the peers?
Are there any plans to address this?
PS. I have only noticed this now with my first 500ms+ lasting transition.
The text was updated successfully, but these errors were encountered: