Use react-plotly.js for Distribution View

[chutten]

Live preview: https://chutten.github.io/mdv2/

Specific things to note:

• resizing is done via a window resize function. Not the best (as it could fire for each and every pixel the size changes) and it breaks encapsulation (why should the plot know or care how big the window is?), but when SVG needs a raw pixel value to paint, you stop questioning and start doing. This method could work just as well for MG.js as it does for plotly.
• The "doesn't crash when it renders" test environment has insufficient DOM mocking for plotly (specifically it doesn't have object: uris), so the test mocks plotly completely out. This means we're not testing plotly, but that might be a good thing as plotly already tests plotly for us.
• All colours, label formats, titles, and so forth are just a first brush. Bikeshedding welcome.

And now the bigger note about Why Plotly and Not MG?

Trying to get MG to render histograms as categorical or boolean data as bar plots encountered the following problems: bar plots require groups bar plot examples on metricsgraphics.js don't work as written bar plots with string axes labels error out histograms with string x-axis values errors out Even a log-linear plot looks strange for exponential data MG's numerical/categorical inference is buggy if the accessor is broken

So I tried plotly and found it much better documented, supported by stackoverflow, and feature-rich for the application I was hoping to put it towards (plotting categorical and numerical bar charts, mostly).

I think I will continue to use Plotly for the prototype given the time constraints.

[chutten]

I was aping mathematical notation (which I now learn is part of ISO 31-11) for inclusive intervals. [n, m] means it includes any x such that n <= x <= m, and (n, m] includes any x such that n < x <= m

[chutten]

Maybe it'd be clearer if I used half-open intervals [n, m) by subtracting one from "end"... and it might be more honest...

If the garbage collector ran for 1261.9ms, would it be in the bucket that starts at 1262 or would it be in the bucket that ended 1261? On the client side we force the code doing the measuring to make that choice by requiring that all samples be integral... we don't support 1261.9, but we do support 1261 and 1262. A naive implementation might round to the nearest, giving 1262... But if someone were really, really knowledgeable about the representation of their histogram they could know that a bucket starts at 1262 and could take that 1261.9 and truncate it to 1261 so that it remains in the bucket its precise representation would have it in.

Or maybe ISO 31-11 is sufficiently obscure a reference that no post-facto justification I can dredge up from my imagination can be used as an argument to keep it when all I really wanna do is not rewrite it : D

[georgf]

[n, m) sounds fine for now if it generally matches what we do. We could go with that and file an issue to consider improvements later?