{"action":"created","issue":{"url":"https://api.github.com/repos/borisyankov/DefinitelyTyped/issues/3999","labels_url":"https://api.github.com/repos/borisyankov/DefinitelyTyped/issues/3999/labels{/name}","comments_url":"https://api.github.com/repos/borisyankov/DefinitelyTyped/issues/3999/comments","events_url":"https://api.github.com/repos/borisyankov/DefinitelyTyped/issues/3999/events","html_url":"https://github.com/borisyankov/DefinitelyTyped/pull/3999","id":65293287,"number":3999,"title":"Add generics to d3.d.ts","user":{"login":"gustavderdrache","id":194893,"avatar_url":"https://avatars.githubusercontent.com/u/194893?v=3","gravatar_id":"","url":"https://api.github.com/users/gustavderdrache","html_url":"https://github.com/gustavderdrache","followers_url":"https://api.github.com/users/gustavderdrache/followers","following_url":"https://api.github.com/users/gustavderdrache/following{/other_user}","gists_url":"https://api.github.com/users/gustavderdrache/gists{/gist_id}","starred_url":"https://api.github.com/users/gustavderdrache/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gustavderdrache/subscriptions","organizations_url":"https://api.github.com/users/gustavderdrache/orgs","repos_url":"https://api.github.com/users/gustavderdrache/repos","events_url":"https://api.github.com/users/gustavderdrache/events{/privacy}","received_events_url":"https://api.github.com/users/gustavderdrache/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-03-30T20:17:40Z","updated_at":"2015-03-31T20:55:50Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/borisyankov/DefinitelyTyped/pulls/3999","html_url":"https://github.com/borisyankov/DefinitelyTyped/pull/3999","diff_url":"https://github.com/borisyankov/DefinitelyTyped/pull/3999.diff","patch_url":"https://github.com/borisyankov/DefinitelyTyped/pull/3999.patch"},"body":"This is a complete rewrite of d3.d.ts and is extensively breaking. By way of apology for the utterly massive pile of changes this brings in, I'm going to list what happened and why:\r\n\r\n## Name Reorganization\r\nAny empty namespace (things like `D3.Svg` and `D3.Geo`) have been removed, along with `D3` itself.\r\n\r\nType names follow the path of their associated constructor function: `d3.rgb()` returns a `d3.Rgb`, and `d3.svg.line.radial()` returns a `d3.svg.line.Radial`.\r\n\r\n## Selections\r\nSelections are now parameterized by their bound data. Most code should be compatible, but usage of the `.datum` method may cause some type issues. This in fact broke a test. Thanks to type unions, usage of `(d, i) => ...` can be inferred even in the object case.\r\n\r\n## Sets\r\nSince `d3.set` only uses string keys, it is no longer generic.\r\n\r\n## Interpolators\r\nInterpolation requires two values: the input value and the resulting interpolated value. This exists largely to support the interpolation of `d3.color` and its subclasses; `d3.interpolate(d3.rgb(\"#000\"), d3.rgb(\"#fff\"))` returns a function of `(t: number) => string`. However, there is a one-parameter variation of `d3.interpolate` that most users will find useful: `d3.interpolate(\"#fff\", \"#000\")` will just work.\r\n\r\n## Scales\r\nDue to the interpolation issue above, scales require two parameters due to their `.interpolate` method. Constructor functions accept single-parameter variations for ease of use: `d3.scale.linear<number>()` constructs a scale whose domain and range are both numeric.\r\n\r\n## Generators\r\nGenerators (SVG graphics, controls, and the layout functions) have zero-parameter variations that accept the D3 default types (i.e., area generators expect `Array<[number, number]>`).\r\n\r\n## Layouts that Write to Values\r\nLayouts like `d3.layout.tree` write values to their input. I've mimicked this with a type called `Result` which has a suite of the optional properties that are populated on a node. Input values are expected to extend this interface. Since the values are computed, they are not required on creation.\r\n\r\n## Inheritance\r\nD3 uses inheritance very, very sparsely. I removed any base types. They became incredibly difficult to sustain due to the way D3 changes some methods around.\r\n\r\nThe biggest offenders here are the generators and their radial equivalents. `d3.svg.line.radial()` actually creates a `d3.svg.line` under the hood, but it deletes the `x` and `y` methods, renaming them to `radius` and `angle`. It is much easier to treat the line and its radial equivalent as disparate types.\r\n\r\n## CSV, TSV, DSV\r\nDelimiter-separated value parsers return property bags of type `{ [key: string]: string }` instead of `any`. \r\nThe code is parameterized over row functions, so most code will need to change uses of `d3.csv` and friends to include a row function. This is most apparent in the tests, which relied on the `any` type to pretend that the data was pre-converted.\r\n\r\n## Overloads\r\nD3's flexibility was extremely difficult to work with in places. I think I captured most of the spirit. However, I may have missed some edge cases. See also the `d3.extent` tests, where I had to disable some invocations because TypeScript 1.4's lib.d.ts thinks `Number.prototype.valueOf` returns an `Object` instead of a `number`.\r\n\r\n## Other Changes\r\nI had to rewrite `d3.layout.cloud`. It follows the pattern established by other generators, and is generic over the result interface `Word`.\r\n\r\n## Open Issues\r\n* The handling of `Event` is less than ideal. D3 likes to attach arbitrary properties, and it's hard to guarantee when they exist and when they don't.\r\n* What D3 considers a \"scale\" varies from control to control. I ended up defining a `Scale` interface that represented what that particular control used.\r\n* I have more than likely broken the dcjs typings. I'm not familiar with dcjs, so I was only able to make minor changes.\r\n* I haven't added documentation comments for most of the types, functions, and modules in this library.\r\n* There is a really strong probability that these types are overly precise."},"comment":{"url":"https://api.github.com/repos/borisyankov/DefinitelyTyped/issues/comments/88241946","html_url":"https://github.com/borisyankov/DefinitelyTyped/pull/3999#issuecomment-88241946","issue_url":"https://api.github.com/repos/borisyankov/DefinitelyTyped/issues/3999","id":88241946,"user":{"login":"mtraynham","id":5741321,"avatar_url":"https://avatars.githubusercontent.com/u/5741321?v=3","gravatar_id":"","url":"https://api.github.com/users/mtraynham","html_url":"https://github.com/mtraynham","followers_url":"https://api.github.com/users/mtraynham/followers","following_url":"https://api.github.com/users/mtraynham/following{/other_user}","gists_url":"https://api.github.com/users/mtraynham/gists{/gist_id}","starred_url":"https://api.github.com/users/mtraynham/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mtraynham/subscriptions","organizations_url":"https://api.github.com/users/mtraynham/orgs","repos_url":"https://api.github.com/users/mtraynham/repos","events_url":"https://api.github.com/users/mtraynham/events{/privacy}","received_events_url":"https://api.github.com/users/mtraynham/received_events","type":"User","site_admin":false},"created_at":"2015-03-31T20:55:50Z","updated_at":"2015-03-31T20:55:50Z","body":"Mmm yeah, I see what you're getting at when you add in the context of the accessors.  I'm still on the fence because there is now the expectation that you only have to pass an `any` functor, which may/may not contain `domain` and `range` (or `rangeBand`) properties, even though dc expects them.\r\n\r\nFor instance, dc's coordinate grid does make the assumption that it is being passed a valid d3 scale:\r\nhttps://github.com/dc-js/dc.js/blob/develop/src/coordinate-grid-mixin.js#L25\r\n\r\nI've looked over a lot of the other changes.  LGTM.\r\n\r\nI did mean to ask one last thing:\r\nhttps://github.com/gustavderdrache/DefinitelyTyped/blob/master/d3/d3.d.ts#L1309\r\nIs that valid?  I tried that in a [previous request](https://github.com/mtraynham/DefinitelyTyped/commit/516266a0ac7cc5f8b4e64ae9998121ff9306aad5#diff-9eb3fdff1a5a5638bdfa7d4c2c84ff00R853) and Webstorm seemed to complain about using `typeof` within the method signature's arguments.  I know Webstorm has had it's own share of problems, but I think I was on TS1.3 at the time, and don't remember if the tests passed or not."}}