A library for high performance LiveView animations

Your Libraries & OS Mentoring Seeking Feedback
,
1

In the last couple of days I was playing around with LiveView, function components and animations. I ended up with a little prototype which allows you to control animations directly from the server.

The key difference is, that the actual animations will happen in a very performant way directly on the client. So there is nothing like “send every animation frame over the wire happening”.

What do you think about that? I’m thinking to turn this into a library.

Here a little demo video: https://cleanshot-cloud-fra.accelerator.net/media/26144/JoVUJgqmm21U6URHXo5RBP8haH0NZOZQayGHEMYL.mp4

25 Likes
2

The link above looks suspicious… I wouldn’t click.

Update, indeed, the link has been updated and it is safe to watch.

1 Like
3

Sorry, I could not find a way to embed a video here. I updated the link with a “direct” Link to the video. The link contains an online player.

Edit: Seems like it automatically detects video link. Should work now.

2 Likes
4

That’s pretty neat! I wonder how <.motion /> is implemented?

Quite nice how you can abstract away things such as animations using Phoenix function components. It reminds me of React.

I assume every animation frame is sent over the wire via LiveView (using slightly different style attribute).

Oh, and this is quite a stretch perhaps, but if you turn this into a library it would be nice to have an option to enable client-side animation. Cause I can imagine if a user is on a less stable connection (on mobile for example) the animation may not be so smooth.

^ Oh I misread, the animations do happen client side?

1 Like
5

Exactly, the animations fully happen on the client. The only thing which is sent over the wire are the animation props animate and transition. There is also a prop initial which allows you to set an initial state (think of enter animations where you need the state to be something else on initial mount).

This also works flawlessly when re-triggering animations. When you hammer the button in the video, it will just animate in the other direction from the exact point when you clicked at it. You can even do complex animations with multiple steps by just providing e.g. animate={[x: [0, 200, 100, 50, 100]}.

The function component itself currently is extremely simple. I’ll just paste it.

def motion(assigns) do
    rest = assigns_to_attributes(assigns, [:animate, :transition, :initial])

    initial =
      case assigns[:initial] do
        nil ->
          nil

        initial ->
          (initial || assigns.animate)
          |> LiveMotion.Style.create_styles()
          |> LiveMotion.Style.to_style_string()
      end

    assigns =
      assigns
      |> assign_new(:animate, fn -> [] end)
      |> assign_new(:transition, fn -> [] end)
      |> assign(:style, initial)
      |> assign(:rest, rest)

    ~H"""
    <div
      id={@id}
      phx-hook="Motion"
      data-motion={LiveMotion.animate(@animate, @transition)}
      style={@style}
      {@rest}
    >
      <%= render_slot(@inner_block) %>
    </div>
    """
  end

There is a phx-hook involved which utilities a tiny JS library (motion.dev) that performs animations using the browser WebAnimations API.

I took heavy inspiration in the API from framer-motion (Production-Ready Animation Library for React | Framer Motion). I really like their api design and the paradigm for declaring animations. Still, I have to implement a few features and figure out things, like:

  • Exit/Unmount animations (Presence).
  • Declaring animations for pure client side interactions. My idea here is currently a thin wrapper around LiveView.JS.
  • Dependant animations (layouts).
  • Scroll animations
  • Gestures, …

A lot of ideas, but I think in general most of it is somewhat possible.

9 Likes
6

I’m pretty amazed what you can do with LiveView. I just played around with declaring fully client-side interactions using a thin wrapper around LiveView.JS.

Toggle animations declared on the server, performed on the client without a round-trip. And you can even mix and match animations being updated from the server and the animations already running locally :exploding_head:.

When clicking the square, the server updates the LiveView state, therefore updating the animation (again, it just sends one single declaration, nothing more).
When clicking the “Toggle me” button, no round-trip is made.

Hammering both just smoothly animates. Feels magical to me.

9 Likes
7

Wow, this is seriously awesome!! Would love to experiment with it if you end up releasing it as a library. :slightly_smiling_face:

3 Likes
8

Fantastic addition to the live view paradigm. I feel at this point you have no choice but to release it as a library, to be honest. :laughing:

With the upcoming changes in master this will be even more powerful

8 Likes
9

What @03juan said^^ :003:

3 Likes
10

Thanks for the feedback. I appreciate it very much. So as I have quite a lot of fun building this anyway, I’ll release this as a library. It’s still missing a few features and tests - and docs of course.

I’ll have more time to work on it in a week, so I expect a first releasable version in two weeks or so. I’m pretty excited what else can be achieved here.

6 Likes
11

Funny how I spent this week thinking about animations in LiveView :grin:

Animations seemed to be the only missing convenience that’d make Elixir Desktop a competitive mobile framework.

Now it seems that’s being solved.

Kudos @benlime

4 Likes
12

Elixir Desktop seems really nice. I’d love to give it a try sometime! It’s absolutely awesome that LiveView can be used to create native applications.

Meanwhile I got seamless page transitions running. It’s as easy as just defining an exit prop to the motion component. There are three awesome things happening with it.

  1. Automatically animate exits triggered from the server. This happens for example by a conditional render based on a prop. (e.g. @is_visible or something like this).
  2. Trigger exits manually by e.g. binding it. phx-click={LiveMotion.JS.hide(to: "#main-content").
  3. Automagically handle page transitions triggered by e.g. live_redirect.

Can’t wait until I can ship the first version of the library.

EDIT: If you like to see it live, you can test it on https://benvp.co (which is my little page :wink:)

Here is a quick demo:

11 Likes
13

That looks amazing :heart_eyes:

Do you already have an idea what the installation/setup would look like (aside from installing a hex package of course)?

  • npm install motion
  • and install/copy custom hook, I suppose?
2 Likes
14

As the default phoenix installation moved away from adding node I’d like to make the installation as easy as possible without requiring node. So probably I’ll bundle the motion package inside the hex package. I might provide an option to pass the functions from motion during the setup in case somebody wants to use npm instead.

The setup currently looks like this:

image
image1608×1242 65 KB

I’d like to remove the need for manually adding handleMotionUpdates, but currently it’s a little ugly to move this logic into the hook. I opened up an issue in the LiveView repo for the one who is interested Hooks: pass the new element into beforeUpdate · Issue #1940 · phoenixframework/phoenix_live_view · GitHub

7 Likes
15

For what it’s worth handling it in the dom update makes sense to me as it’s the same way that vue.js is meant to be propagated and as Chris says it’s the way to go.

3 Likes
16

I released the first version of the library → See 🍿 LiveMotion - High performance animations for Phoenix LiveView

9 Likes