Best Practices for Animations

[Taigistal]

I can think of two ways in which I can implement animations with the Interactivity API:

1. Change a class with the data-wp-class directive and use CSS Transitions.
2. Animate a value in the context or state with something like AnimeJS and bind the animated value via data-wp-style.

The first is very flexible but limited in terms of animation options, for example if you want a spring animation.
I find the second one very inflexible and a lot of writing work.

So a few questions about animations I stumbled across:

1. Are there other ways? For example, is it possible/useful to animate elements with the Web Animation API?
2. Would it be possible/useful to use Swiper JS with the Interactivity API? Does it make a difference whether I use the Swiper web components or not?
3. Will there be a transition directive in the future, similar to the one in Alpine JS? Are there other considerations to further simplify animations with the Interactivigty API?

Unfortunately, my understanding of how exactly the rendering works is probably too poor to figure out the answers myself.

Thanks for your help.

[luisherranz]

If we create directives like data-wp-transition and data-wp-animate similar to those in Svelte (transition, animate), would that solve the problem?

[Taigistal]

This definitely looks interesting. I think a list of examples like this would be very helpful in the documentation.

I think what I'm still thinking about is how far you can basically work with external libraries that interact directly with the DOM.

There are so many libraries like Motion or GSAP etc. that interact with the DOM themselves. And then also WAAPI. And then of course there are libraries like SwiperJS, which handle large functions autonomously with vanilla JS and where you only specify a container element.

Do you know what i mean? I can achieve a lot with the Interactivity API as it is, but I often have to build functions in my own way that I would otherwise have built in with external libraries.

I would find a guideline helpful here. Should external libraries that interact directly with the DOM not be used with the Interactivity API at all? Is there an advantage if I e.g. initialize SwiperJS in a data-wp-init callback (e.g. for the dynamic page transitions)?

I would be very grateful for your thoughts on this.

[luisherranz]

Oh, I didn't use the library you mentioned because I found it simpler and more efficient to do it with CSS, and because I wanted to show how the animation would be generated using the Interactivity API.

But you can use that library if you want: https://stackblitz.com/edit/vitejs-vite-c2v12s?file=main.js,index.html

Just keep in mind that if there are modifications in the DOM that are not made through the Interactivity API, they might not persist during client-side navigations. After all, the Interactivity API is essentially a Preact application, so the same limitations that (P)React applications have when the DOM is modified outside the framework exist in the Interactivity API.

For that reason I was suggesting whether it would be nice to create some official directives such as data-wp-transition and data-wp-animate, similar to those found in other frameworks like Svelte, so that:

1. They are compatible with the Interactivity API and client-side transitions.
2. There is a standard so all the blocks (or most of them) use the same library for their animations to avoid each one including different libraries which would impact the amount of JavaScript the user has to download and, ultimately, the performance.

[Taigistal]

Thank you; this is helpful for me to understand. I think for anyone who wants to convert their blocks from Vanilla JS (or good old jQuery) to the Interactivity API, it is helpful to understand how to deal with external libraries. Maybe this is something for the Frequently Asked Questions: Can I use external libraries together with the Interactivity API? (Maybe that was just my question.)

I would be absolutely thrilled if there was something like data-wp-transition and data-wp-animate. In my opinion, it would be perfect if there were as many animation best practices as possible. Animations are the most common reason why I need Javascript in the frontend for a block.

If you still have the option to use external libraries in certain cases (even if you then have to fix client-side navigation for your block), I think that would be perfect.
Will the wp-init directive be triggered every time a block shows up after a client-side navigation or only on his first appearance?

[luisherranz]

Will the wp-init directive be triggered every time a block shows up after a client-side navigation or only on his first appearance?

The data-wp-init directive runs when the element is mounted, that is, when it appears in the DOM. It is essentially sugar syntax for a useEffect with an empty dependency array:

useEffect(callback, []);

Whether it runs after a client-side navigation depends on whether the block and the element themselves already existed in the DOM or if that block and element are new and being created at that moment.

The directive that runs every time the element is rendered is data-wp-run. Maybe that one would be more useful in this case.

[Taigistal]

i think we can close it for now. Maybe we can reopen it if i run into limitations with my animations. Thanks for your help.

[stokesman]

for example if you want a spring animation

A bit of digression from your question but all modern browsers now support the linear() easing function and it can be used to create spring easings. It’s not something you'd want to write by hand and it’s a predefined easing so not the ticket if you need a dynamic physics-based one (say responding to a user gesture which should input the initial velocity).

[Taigistal]

Thanks for the tip. I didn't know about the generator yet. I think in many cases that can be enough.