Provide a way to lock/unlock elements purely client-side

[SteffenDE]

When using external libraries like motion.dev with LiveView, we'd ideally have a way to trigger those animations similar to how we do a JS.transition. The important part is that we'd want to support locking the elements to prevent them from being patched while the animation is running.

I think we could extend the JS commands (on the client) to also support a locking API, which we could then handle similar to how we handle locked elements for regular server events (patching a clone in the background and applying the updates on unlock). We should also handle those locked elements in phx-remove to allow custom animations when an element is removed.

cc @chrismccord @bcardarella

[bcardarella]

Thanks @SteffenDE. i'm currently using JS.dispatch to send to an event listener to trigger Motion's animation.

It was suggested to use JS.transition to manage the "locking" but timers in JS are not precise and I'd rather have explicit control from Motion's own complete/cancel callbacks on when to unlock elements.

[SteffenDE]

For phx-remove it is probably important to lock the whole DOM like JS based transitions do. So that might be a separate feature. Maybe we could just have

liveSocket.transition((done) => {
  // all DOM patching is paused for now,
  // animate and finally call done
  ...
  done()
})

as public API, but element-level locking might be interesting for other things?

[bcardarella]

@SteffenDE what are your thoughts on being able to pass a promise to the lock itself? That way when the promise resolves or is cancelled the lock will disengage? It should probably also have a timeout so you aren't stuck in a locked state

[ssalv]

Hey @SteffenDE , I have the same issue ( but not only for animations but mostly for components ) , for example dropdown using just client state to avoid to keep this information on the server.

IMHO more than create a Promise callback (un)block i would suggest more a way similar to this ( allow to ignore specific element's attribute by phx-something-ignore-attrs or in the hook using this.ignoreDOMPatchAttributes([ "style" ]);

I created a test PR to check, something similar to this: #3574

[bcardarella]

Is this under consideration at all? I'd like to know if I should continue with the motion JS command wrapper, without this feature I don't think it's worth continuing.

[bcardarella]

I spoke with @chrismccord and I want to provide my understanding of what Chris's position is (if I'm misunderstanding this please correct me) as well as my feedback on what I understood.

Chris said there were two methods currently available to do what I want. The first is to lock the entire UI during the animation. The second is to use the JS.transition command.

My posisition is that neither solve the problem and are a misunderstanding of the underlying need.

Locking the entire UI is a non-starter. IMO LiveView shouldn't care if a client-side async events runs for 1 second or 100 years. The node's tree should be locked until the callback/promise/or a given timeout happens. (timeout should be optional but recommended so UI doesn't permalock). Locking the entire UI means that updates that are applied outside of the target element's sub-tree should still be able to update and I don't understand why this was a recommendation. It feels very counter to the position that LiveView is a modern client-side alternative to SPA reactive libraries which would never present this as an option.

Using the transition command for a timeout is also a very bad idea. Duplicating the timeout value may be something you can get away with every so often but should never be depended upon and will introduce race conditions. Again, the lock should be lifted after a callback/promise/or fallback optional timeout to prevent permalock.

Finally, having a formalize public API for this need will open the door to more interoperability with the wider JS ecosystem which is what we've been trying to tell people outside of Elixir that LiveView plays nice in that space. Currently, I don't think that's true without being able to properly introduce a public API for this.

[SteffenDE]

@bcardarella can you maybe show an example where locking is needed? I just tried a simple motion example of rotating a box and even with DOM patching inside, it works just fine: https://gist.github.com/SteffenDE/498469e6531a7ba8b9ba73d4dc32d5ca

So an example where the current way of integration is a problem would be helpful.

[bcardarella]

@SteffenDE have your update delete the element from the DOM

[SteffenDE]

okay, so we're specifically talking about the phx-remove case, that helps :)

[bcardarella]

@SteffenDE no I'm talking about how LV can patch when another async operation acting upon that element is already in-flight.

[SteffenDE]

I do think is is worth differentiating this though. Many updates can be applied without problem while things like animations or "another async operation" are running. But this doesn't apply when an element is removed.

How would an API you'd like to see look like?

[bcardarella]

@SteffenDE yes but it should be up to the developer to make that call.

I described the API here #3516 (comment)

[SteffenDE]

@bcardarella I thought about this a little more and came to the conclusion that those are separate issues. Locking elements to prevent DOM patching only for the element is something where I don't necessarily see the need for at the moment, but you can convince me if you can provide an example where it is indeed needed. For animations using external libraries, I propose #3615.

This adds JS.dispatch(event, blocking: true) which can be used to lock the whole DOM until the event handler calls event.detail.done().

It also adds liveSocket.asyncTransition(promise) which can be used from hooks

liveSocket.asyncTransition(async () => {
  await animate(...)
})

The important part is that you'll probably only want to use blocking: true or asyncTransition if your animation is used when the element is removed.