An interface is needed to disambiguate transition.ease(ease) from transition.ease(function), where the latter is a function that returns an easing function, thereby allowing different easing functions to be used for different nodes in a transition. This is the same issue that lead to the creation of the symbol type interface in d3-shape, which is useful for applying a categorical symbol encoding to a scatterplot.
Admittedly, I don’t anticipate a lot of demand for customizing the easing function per node, but if we didn’t support it, the inconsistency is likely to lead to occasional confusion.
It’d still be nice if you could have optional parameters, though. Not sure how to do that…
transition.ease(d3.easePolyIn, 2);
Maybe if there’s more than one argument, it automatically gets converted to this?
transition.ease(d3.easePolyIn(2));
Well actually that wouldn’t work, because if you didn’t specify the optional argument, then the parameterizable easing function factory would get invoked separately for each node.
transition.ease(d3.easePolyIn); // Oops, an ambiguous function again!
Alternatively, the non-parameterizable easings could still be functions that return easing instances, so these would be equivalent…
transition.ease(d3.easeLinearIn);
transition.ease(d3.easeLinearIn());
But that means you’d need to do some manual easing, you’d need to change this:
var t = d3.easeCubicInOut(0.123);
To this:
var t = d3.easeCubicInOut().ease(0.123);
Which is a little verbose. (And slower, unless you stash the result of d3.easeCubicInOut() outside of your animation loop.) But then the transition.ease API is probably going to see wider use than the d3-ease API, and it’s not like the proposed API is bad. You can approximate the old API like so:
var cubicInOut = d3.easeCubicInOut().ease;
var t = cubicInOut(0.123);