With lifecycle events going away #717, what options do we have to animate elements and can Hyperapp offer declarative animation hooks out of the box to help library authors?
I'm not expecting to have anything else except Hyperapp when using import { h, app } from 'hyperapp'. And I'm not using animation on a daily-basis so I don't think it should be built-in. But I'm eager to listening to others' opinions.
I think it's not a priority. In my opinion, we should keep the library as simple as possible and animation should be handled by other libraries, including the entire process.
I think to pull off declarative animations, we need hooks into the patching cycle, so we can see the DOM before & after (at an arbirtrary VNode, not just the whole tree).
React has getSnapshotBeforeUpdate and componentDidUpdate, which enabled this new library to do really nice FLIP animations (albeit with somewhat complex code): https://github.com/aholachek/react-flip-toolkit
snabbdom's "hero" module is another example which is enabled by exposing those before/after-patch hooks.
Vue's built-in transition components hooks into the vdom in a similar way (likely because it was originally based on snabbdom).
@jorgebucaran Were you thinking of something higher-level?
@SkaterDad
Remove lifecycle events and follow the footsteps of Elm's elm-style-animation package. Another option (that does not conflict with the aforementioned state-first only solution) is an animation library based on mutation observers.
Expose a declarative, higher level API that uses our current lifecycle events under the hood. We can use popmotion/pose for inspiration. This path does not conflict with either of the options suggested above.
I want to proceed with (1), but also interested in how (2) could look like.
Something like @zaceno's hyperapp-transitions API { Enter, Exit, Move } sounds like a good place to start perhaps for (2).
I tossed @hyperapp/transitions into a pot with MutationObserver and customElements, and let it all boil together into a framework agnostic custom element: <transition-group> with a similar behavior as the <transition> tag of Vue.js.
The implementation is definitely not elegant by any means (marrying the contorsions of @hyperapp/transitions with the cludgy lifecycle-hook-emulation of mutation observers). It's probably the least fun programming I've had in a long time. But it works.
Here are the examples from @hyperapp/transitions ported to use my <transition-group> instead:
And here's the codepen with the "implementation" 馃あ : https://codepen.io/zaceno/pen/qKwXXK?editors=0010
Unfortunately we can't have the nice {Enter, Exit, Move} API this way, because all transitions applying to an element all need to be handled by the same MutationObserver.
@zaceno Thank you, for putting that together. 馃檱
First implementations are never as fun as later ones!
Built-in animation support in Hyperapp is out of the question for the foreseeable future but never say never. We may get back to this idea again someday.
Most helpful comment
@zaceno Thank you, for putting that together. 馃檱
First implementations are never as fun as later ones!