Skip to content
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

Histogram events #2071

Closed
alexcjohnson opened this issue Oct 6, 2017 · 6 comments
Closed

Histogram events #2071

alexcjohnson opened this issue Oct 6, 2017 · 6 comments
Labels
feature something new

Comments

@alexcjohnson
Copy link
Collaborator

Currently histogram trace events (click, hover, selecting, selected) yield the bin number in the pointNumber field, and don't do anything to connect this back to the input arrays. That seems awkward for applications like crossfilter. How should we handle this?

  • (1) Leave it as is, let the developer work it out.
    • pro: Small event data. Direct correspondence between the event on screen and the event data. Also inertia!
    • con: It can be cumbersome (and slow) to work out the bin contents. Also pointNumber isn't actually a point number (ie you can't look up items in gd.data from this)
  • (2) Report one point for each item in the selected bin, and don't report the bin itself at all
    • pro: Most natural for crossfilter, as we connect directly back to the input arrays. In as far as this is what you care about, there's no special case to deal with histogram traces, they work just like other traces.
    • con: Event data could become huge and slow to create. What about empty bins, we wouldn't be reporting anything even though (for click and hover events) there is hover data there. Devs still may want to know what bin is being selected.
  • (3) Keep the current structure, but add an array of actual point numbers to each bin data object. Perhaps bin number could move from pointNumber to binNumber and the associated input data could be an array, pointNumbers?
    • pro: report all the things! Doesn't have as much overhead as reporting a whole point for each item, either in object size (an array of numbers vs an array of objects with lots of keys) or in CPU (we could probably construct all these arrays of indices during histogram.calc with minimal overhead, and just spit them out on demand)
    • con: histogram becomes a special case for any event-handling code - that said, you won't need to switch on trace type per se but just on the structure of the event data you get. And other traces may follow, for example looking at https://simonbjohnson.github.io/Ebola-3W-Dashboard/ I notice the pie charts are really aggregated like histograms - separate issue on the topic forthcoming, I think this is in fact a very common use case.

I'm leaning (3) but would love to hear opinions particularly from @cpsievert @chriddyp @monfera

@cpsievert
Copy link

(3) seems reasonable to me

@alexcjohnson alexcjohnson added the feature something new label Oct 6, 2017
@chriddyp
Copy link
Member

(3) works for me

@monfera
Copy link
Contributor

monfera commented Oct 11, 2017

seconding (3)

@etpinard
Copy link
Contributor

(3) ftw 🥇

@etpinard
Copy link
Contributor

ping @alexcjohnson

looks implements #### doesn't close issues automatically.

@alexcjohnson
Copy link
Collaborator Author

closed by #2113

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature something new
Projects
None yet
Development

No branches or pull requests

5 participants