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

%JS{} based transitions block all interaction with LiveView instances until the transition has finished #3101

Closed
DaTrader opened this issue Feb 8, 2024 · 4 comments

Comments

@DaTrader
Copy link

DaTrader commented Feb 8, 2024

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.

@chrismccord
Copy link
Member

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!

@DaTrader
Copy link
Author

We necessarily have to lock the DOM during a transition

If I understand it correctly, this locking seems like the culprit behind the following two types of issues:

  1. The client-side js crashing on a concurrent update while a transition (locking) is taking place (issue Client-side js crashes when component with phx-remove set to JS.hide navigates to another LiveView #3139) - this applies to both async tasks and nested LiveView processes

  2. The occasional failure of AlpineJS to initialize its data.

As suggested in the #3139, I have proven this relation b/w using JS.hide and friends and async updates, but I thought it was a bug. In both cases, removing the JS module based transitions seems to circumvent the bug manifestation.

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 JS module transitions can only be safely used in the simplest of apps where none of the following apply:

  1. Having multiple/nested LiveViews
  2. Having async updates
  3. Integrating LiveView with a JS framework like AlpineJS

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 JS.hide, JS.show and JS.transition.

In addition, it will be of great help knowing if there are other situations (besides transitions) where you lock the DOM.

Thanks

@SteffenDE
Copy link
Collaborator

fyi: there’s a blocking: false option in LiveView 1.0-rc.6 that can be set on all JS functions that accept a transition

@DaTrader
Copy link
Author

DaTrader commented Aug 5, 2024

Thanks, will consider it once LV1.0 final is out. For the time being I'm sticking to 0.20.17

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

3 participants