Animate from state to state about few.swift

[joshaber]

Yeah this is tricky :\ Presumably we want to use Core Animation to do the interpolation. It's not terribly clear to me how we can treat the animation as a function of state while still allowing Core Animation to do its thing.

[mrjjwright]

When Few brings in new elements, removes elements, or updates elements it simply adds, removes or updates them. This could be done as a transition, similar to a React transition group or the UICollectionViewLayout protocol where the layout asks for starting and ending properties from a source. Perhaps the Few way could be to add an optional returned struct from render (or perhaps wrapping the returned elements as React does) that describes the transition, including any desired animation. Things to specify about a transition could include specifying the start frame for an added element. Instead of just adding an element at it's final computed layout frame, another layout could be specified that describes a start frame. Then the added element could be animated to it's final layout using other properties in this same struct. The struct could be keyed by element key plus a string. Like key1.start or key1.animationDuration.

[mrjjwright]

So thinking about this a little more, Few doesn't have an abstracted layout object on each element, instead the flexbox attributes are directly on the element. This isn't the most ideal since layout could be abstracted a bit to support times when custom layouts are needed. However, support for this needs to be added directly in css-layout since it manages all measurement and layout of children and I think @vjeux has mentioned he wants to do this. But at any rate, if there was an external layout it would be an ideal place to be consulted for any transition properties for an element.

[vjeux]

You can provide an arbitrary C measure function to css nodes to do layout. This should give you the same power as sizeThatFits (but someone needs to actually test it).

[vjeux]

I just want to mention that while this would be a nice to have, position: absolute with top, left, width, height solves most of the use cases if you can workaround to find the size of your parent. So it hasn't been critically needed in any of our apps yet.

[mrjjwright]

There is this idea that might appeal to you @joshaber with an FRP based approach: https://github.com/chenglou/react-state-stream.

[joshaber]

I definitely like the conceptual purity to that. 👍

A couple immediate thoughts:

1. It's hard to see how that would fit with allowing Core Animation to do the interpolation.
2. I wonder if it would end up making life harder on users. They'd need to reify all state involved in their animations. That might be more correct as it is view state, but maybe more awkward to use?

[mrjjwright]

It’s a really convoluted approach. I am not sure even why I sent it along. :)

[joshaber]

Oh no, I think it's definitely interesting. Especially in the sense that it's true to the "views as functions of their state" description.

[adamjernst]

I'm really interested in being involved in this discussion. We're open sourcing ComponentKit shortly — we should compare implementations after that.

[joshaber]

(:metal: Can't wait to see ComponentKit!)

[joekim]

Really interested to see how the thinking around animation evolves. My first two gut reactions are to have multiple animation APIs:

1. A simple approach where you can attach an animator object to a view that describes things such as animationDuration and animationCurve. Perhaps animations are triggered by adding the animator object and when the animation completes it requests the animator object gets removed.
2. An advanced approach that could take advantage of libraries like AsyncDisplayKit and that invokes updateState every animation tick. That way more complex Facebook-Paper-like gesture/animation relationships can be handled.