But I'm open to persuasion if you think I've got that wrong. One thing I haven't considered here is the Web Animations API I've been assuming that we'd use CSS animations which I think are probably more suitable. allow transition functions to return a function instead of a transition object.animate directive that works inside keyed each blocks.To recap, the bits I think we should add: I would love to know if there are parts to this that I've overlooked, or any trickier use cases to test the ideas against, or if you have improvements to the above proposals. Any new elements will be introed, if an intro was specified.Īs an aside, css: t =>.
delay, duration and easing would also be respected, just like with transitions. if it returns a css function, that will be used to create a CSS keyframe animation that smoothly animates the element to its home position. It returns the same kind of object that transition functions do - i.e. The animation function - flip, in the example below - is responsible for using that animation object to calculate CSS.
#Animations brain plus
We create an animation object for each element that moved, containing layout information (we can probably get away with just the change in x and y value, plus maybe some other stuff like actual distance moved). 
For that to work visually, we need to set position: absolute on those elements and use transform to make it look as though they haven't moved, and only then run the outro
Any items that have been removed from the list need to be transitioned out, if a transition was provided. The bounding box of every element inside the block with the animate directive is measured. Whenever a keyed each block updates, the following sequence of events happens: Vue appears to have reached the same conclusion - FLIP animations can only happen inside, and each element must have a :key. We do, however, have a primitive that lets us reorder things on the page - the keyed each block. We have a concept of transitions, but we don't have a concept of animating something from one place on the page to another. Stretch goal 2: z-index should preserve the apparent z relationships between elements if a reshuffle happens during an animation. Stretch goal: we want to preserve momentum, or simulate springiness. (But we want them to be powered by CSS animations under the hood for the perf benefits etc.) Maybe we don't want to travel in a straight line maybe we want to change scale along the way - in other words we need fine-grained parameterisation and programmatic control, not just CSS transitions. (See react-flip-move and Vue for prior art.)īut we don't want a fixed duration we might want duration to be dependent on distance to travel, or on bounding box size (to simulate 'mass'). We want to move elements smoothly to their new position using a FLIP-like mechanism. I'm going to describe three particular scenarios based on examples from Edward's talk, and suggest the primitives that we need to add to Svelte in order to make them easy to do. I urge anyone who is interested in this stuff to watch Living Animation by Edward Faulkner, which was recorded at EmberConf recently. Most of what I'm about to describe is almost certainly possible already, but I don't think it would be at all easy or declarative. We don't have a good way to achieve certain effects that are rightly gaining in popularity among web developers. (There are also some outstanding issues that need to be resolved one way or another - #544, #545, #547 and #1211, which is related to #547, spring readily to mind.) Svelte's transition system is powerful, but only applies to a fairly narrow range of problems. 
I just want to get this stuff out of my head and into a place where the missing pieces will hopefully be a bit clearer. Fair warning: this will be a long rambly issue.
0 kommentar(er)
