property or method on scale to return scale type

[boygirl]

I would love to be able to easily determine what type of scale is in use so I could do things like filter out zeros for log scales.

[mbostock]

Well, the normal way of doing this would be x instanceof log, but that isn’t possible (in ES2015) since a scale is a function, not just an object, and thus does not have a standard constructor.

You best bet for testing whether something is a log scale is to look for x.base, i.e., check for the existence of the log.base function. Duck typing seems reasonable to me, here.

I’m not sure that I want d3-scale to enumerate the set of scale types because it should always be possible for people to define new implementations outside of d3-scale that mimic the scale interface. I suppose we could use a string name… in fact, you can already look at x.name which returns function.name. But that name gets minified currently (and the non-minified name is "scale", at the moment, but it would be easy to change), so it’s not a great check.

[boygirl]

Thanks for the tip about scale.base. That will help with my immediate problem.

I guess what would really be great would be a function I could call that would return the type of the scale. Duck typing will work in this instance, but I would really like to do the right thing (or throw helpful errors) for all the d3 scales (d3 v4 scales)

[mbostock]

I would really like to do the right thing (or throw helpful errors) for all the d3 scales

Right. I’m just saying that list is (at least in theory) unbounded, so you’d always need a default case in your switch statement to deal with an unknown scale type, in which case it’s not that different than an if-else statement with the appropriate duck test for each scale type. Having such a method would encapsulate those tests, but I’m not sure it’s a good idea to encourage this pattern. 😀

[boygirl]

Unbounded in theory, but in practicality, the vast majority of users will just use one of the scales you've already written, IMO. But actually, I think this conversation has given me a few thoughts about better ways to keep things from breaking. Thanks!

[mbostock]

Thank you. I’m going to close this because I have no immediate plans to add this feature, but we can reopen the discussion in the future if the need becomes apparent.

[mhkeller]

I'm wondering if this is worth revisiting. I'm looking to check what kind of scale exists and construct an initial domain and range based on the user's data. One could figure out the duck typing by looking at which methods / combinations of methods uniquely identify a scale type but that seems a bit daunting to get right since there are quite a few scale types now. Edit: It would also make it easier to implement things like this in external libraries.

[mhkeller]

I wanted to bump this issue since I'm running into it again with Layer Cake.

I'm successfully using duck typing to determine whether a scale is discrete vs continuous in order to pre-compute the domain for the user (either unique values or the extent). It's fairly easy to determine that by looking at the methods available (here's that script).

I'm also using duck typing to figure out how to add padding via this function per this issue.

But I think I've reached the limit of what I can do with duck typing.

I'm working on a new feature where the library displays all of the calculated scale information and reports it back to the user so they can see their domain, range and type of scale mhkeller/layercake#111. The most common errors people have with the library is the data not being cleaned properly, or the parent div not being sized, resulting in weird domains and ranges. This feature will greatly speed up troubleshooting.

To make this feature work, though, and report the proper scale name, I have to accurately deduce every scale type that D3 offers. I fear it is too much complexity to get right with certainty and it is causing my head to explode. Instead of writing a big system of rules that may not be completely accurate or may change if new methods are added, renamed or removed, it would be great if each function had a name property that I could rely on. I'd be happy to start on a PR for this.

Thanks for taking the time in reviewing this.