The signature of Transition.styleTween is currently:
styleTween(name: string, tween: (datum: Datum, index: number, attr: string) => Primitive, priority?: string): Transition<Datum>; (line 833)
Note that the tween is said to return a Primitive. This seems incorrect, both in terms of D3 intent and implementation.
The *correct* version appears to be:
styleTween(name: string, tween: (datum: Datum, index: number, attr: string) => (t: number) => Primitive, priority?: string): Transition<Datum>;
(This is similar to similar to Transition.attrTween.)
First, the documentation states:
>>> The return value of tween must be an interpolator: a function that maps a parametric value t in the domain [0,1]
>>> to a color, number or arbitrary value.
Second, the source code of d3 3.5.5 has:
d3_transitionPrototype.styleTween = function(name, tween, priority) {
if (arguments.length < 3) priority = "";
function styleTween(d, i) {
var f = tween.call(this, d, i, d3_window(this).getComputedStyle(this, null).getPropertyValue(name));
return f && function(t) {
this.style.setProperty(name, f(t), priority);
};
}
return this.tween("style." + name, styleTween);
};
Note the line "this.style.setProperty(name, f(t), priority);" where the result f of applying the tween is passed a parameter t.
The only point of discussion might be the type of the return value of the tween's interpolator output. Is it Primitive or any? The documentation quoted above (incidentally the same for attrTween and styleTween) explicitly allows for an arbitrary value. I don't have enough D3 experience to know if this is a practically relevant possibility.
Many thanks for your great work on d3.d.ts!!! Especially the use of tweens and interpolators perfectly illustrates the benefits of Typescript.
Best wishes,
Matthias
When passing data to a d3 structure the data can be very flexible.
The current interface of the GraphNode requires many data attributes
to be present, most of which aren't required to draw the
visualization. In fact, d3 calculates some of them itself, so passing
them to the GraphNode would be redundant.
In this example http://bl.ocks.org/mbostock/4063269#flare.json, Mike
Bostock uses the attribute className to identify name and packageName
to identify color in the GraphNode. This means that he doesn't only
ignore all of the attributes DefintelyTyped provides, but comes up
with his own attributes. This means that the data passed in could in
fact be a hashmap/js object type with arbitrary attributes. It's only
when the data is used with d3 methods to identify what attribute
represents size/color etc... that the type becomes relevant.
So either the GraphNode should be less restrictive (or in fact an
arbitrary hashmap) or I've misunderstood some core concept.
You don't have to necessarily merge this pull request, if I'm right
some parts will have to be rewritten (GraphNodes seem to be used
everywhere), but hopefully it might spark some discussion.