Closed gordonwoodhull closed 5 years ago
The current deprecation leads to questions like this one:
Not the first time this has come up. For one, the discussion in #1225 is not conclusive. I've also seen somewhere people switching between different scales based on the data, which is also a reasonable thing to do.
Hi,
I had the same kind of problem as you mentioned for the venture capital, what I ended up doing was:
set up a domain [ -42 /*value that isn't par of the normal range*/, 0, 100]
and color range [color invalid, color for 0, color for 100]
and a color accessor
if value == undefined return -42
return value;
and kind of work, but really clunky IMO.
I do miss the colorAccessor, +1 adding it back ;)
Thanks @tttp, it's good to know there is a workaround but yeah what a mess... why force a scale to perform logic, when the language itself is so much better at it?
More recent versions of d3-scale include .unknown() and diverging scales, which cover some of the use cases for colorCalculator
. However, a function will inevitably be easier in some cases.
I'm fixing this by adding an override function _colorCalculator
, and removing the horrible assignment to .getColor
, as well as the deprecation warning.
Released in 3.0.11; backported to 2.2.2 for all those folks still using d3v3!
Although scales and accessors are bright and shiny, they don't cover all use cases.
In particular, it's much easier to special-case a specific value using the
colorCalculator
, as seen in the venture capital example. I don't know how to create a scale that returns normal values for everything except for one exact value (undefined
in this case).I had two reasons for deprecating this method:
getColor
, which is a horrible horrible thing for a setter to doThe second reason isn't all that good - D3 is not supposed to be a framework that stops you from writing code! Sometimes writing a little logic is better than the best-abstracted toolkit.
The first reason can be fixed without hurting efficiency too much.