dev-docs/RFCs/v7.2/property-transition-rfc.md
Note: This RFC Makes a strong distinction between "animation" and "transitions". For information the distinction, see the introduction, for more information aboutabout property animation, see the complementary RFC about that topic.
References
This RFC proposes a system for transitions or interpolations (not covering animation) of deck.gl layer properties.
Adding animation to an visualization, especially an interactive visualization, can take it from great to extraordinary impact. Well-executed animations add a very deep level of polish and interest. However implementing good animations often requires considerable custom work in applications.
The goal of this RFC is making it much easier for deck.gl users to achieve great animations and almost effortless to achieve good baseline animations, at least for in certain category of visualization property changes.
The following proposals are included in this RFC:
The following types of animations are not included in this RFC.
In deck.gl v7.2:
transitions prop, where accessor names are used as keys.setState internallyThe idea here is that setting a new value on an "interpolatable" props would not immediately make the layer take the new value, but would instead slowly animate the value from it's current state to its new.
This way this would work is similar to how the current deck.gl HexagonLayer demo on startup slowly increases elevation of the hexagon from zero. Except there would be no application code necessary to achieve this. The layer would be set in interpolation mode, and would start rendering
Once a change in value in an "interpolatable" prop has been detected, how long will the animation last?
Options:
Reference: See the separate prop-types RFC
A prop-types system would allow deck.gl to see if a certain property is interpolatable at all. If the prop is an integer or a float, or a color the interpolation strategy is clear, if a function or string we should not attempt interpolation. And deck.gl could start small, and gradually add interpolation support for more types as the system was built out.
More subtly, an advanced proptypes system would contain information about the allowed ranges of various props, which would enabled the interpolation system to calculate the percentage change of the whole range and use this e.g. to influence the interpolation speed (so that the percentual change range would remain constant, a big change would animate for a longer time).
The application may want the ability to control interpolation, at least in two different ways:
A possible design for handling this could be an object similar to updateTriggers that would enable the app to add params for each prop...
new Layer({
elevationScale: 100,
radiusScale: 20,
transitions: {
elevationScale: {duration: 2000, easing: QUADRATIC, ...}
radiusScale: false
},
...
});