Love the library. Small feature request!
Trails would be greatly enhanced with a prop to configure delay between items. Ideally perhaps optionally taking an array that lets you have different delays for each item, or a single number for all.
@natew in the current implementation trails basically follow their parents.
But these primitives are just building blocks around spring, you could copy this: https://github.com/drcmda/react-spring/blob/master/src/Trail.js and make your own rules.
Ok so forked it, but realized the config option delay only works with Timing based transitions. Not sure how to do this with springs.. perhaps do some sort of hold and then setTimeout and un-hold in order?
Would a delay option in spring configs seem as helpful to you as it does to me?
Then Trail's could take a single getProps function that would pass the index for each item, and you could easily set a different delay for each.
All configs support a delay: config={ tension, friction, delay }
or, for time based animations:
impl={TimingAnimation} config={ delay, duration, easing }
https://github.com/drcmda/react-spring#timeduration-based-implementations-and-addons-demo
As far as I can see, delay is not a part of the tension/friction-based config, or am I missing something, @drcmda?
Related to this, I think a delay makes most sense if it's set per enter/leave. The most common use case I can think of is wanting to prevent an element from animating in on top of the leaving element, which a general delay applied to both enter and leave would just... delay... not solve.
I suggest expanding the enter/leave to take a config object rather than just a value per key. Something like:
...
from={{
opacity: {
value: 1,
tension: 20,
friction: 20,
delay: 200, // In ms?
},
height: 20,
}}
...
Generally I think a lot of use cases require a separate config per key per enter/leave. Adding "direction" to the config function like name would make it even more awkward to handle than it already is, opposed to the above suggestion. Admittedly, this complicates the API, and it is a lot like react-motion.
I'd be willing to look into this, if you're accepting PRs.
@ostrgard i removed it because it caused some deeper issues. delay is now a generic prop (<Spring delay={1000} ... />), but for trails it only applies to the first to go.
Configs per key are actually possible, it can take a function: config={k => k === 'x' ? {...} : {...}}. But since delay is out, this probably isn't what you're looking for.
@natew here's an example: https://github.com/drcmda/react-spring/issues/97#issuecomment-392380139
Most helpful comment
As far as I can see,
delayis not a part of the tension/friction-basedconfig, or am I missing something, @drcmda?Related to this, I think a delay makes most sense if it's set per
enter/leave. The most common use case I can think of is wanting to prevent an element from animating in on top of the leaving element, which a general delay applied to both enter and leave would just... delay... not solve.I suggest expanding the
enter/leaveto take a config object rather than just a value per key. Something like:Generally I think a lot of use cases require a separate config per key per enter/leave. Adding "direction" to the
configfunction likenamewould make it even more awkward to handle than it already is, opposed to the above suggestion. Admittedly, this complicates the API, and it is a lot likereact-motion.I'd be willing to look into this, if you're accepting PRs.