-
Notifications
You must be signed in to change notification settings - Fork 289
Treat null as undefined. #241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
No problem in principle, but I believe this might break a lot of applications that rely (knowingly or not) on null being treated as 0. And I don't see a way to evaluate the risk (eg by searching for examples in blocks or observable). |
I am confident we can proceed with this as a patch release. I think it is more likely that null data is inaccurately being misrepresented as zero than people are relying on null implicitly representing zero. |
null in quantitative scales is now considered an “unknown” value. d3/d3-scale#241
null in quantitative scales is now considered an “unknown” value. d3/d3-scale#241
* Allow delay in history graph * Upgrade d3-scale null in quantitative scales is now considered an “unknown” value. d3/d3-scale#241 * Fix history mix graph * Update check as production is always present * Make area graph handle null values * Make time slider hourly * Only run validation when production values are there * Add preview flags to API calls * Upgrade build image for d3-scale * Fix timeslider timescale Co-authored-by: skovhus <kenneth.skovhus@gmail.com> Co-authored-by: Kenneth Skovhus <skovhus@users.noreply.github.com>
I’m surprised we didn’t find this sooner, but I think it’s appropriate for quantitative scales to treat null as undefined, rather than implicitly coercing null to zero. This makes d3-scale more consistent with d3-array.