-
Notifications
You must be signed in to change notification settings - Fork 187
the Plot.stack offset option can be a function #814
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
…c bars following a Likert scale)
README.md
Outdated
@@ -1866,6 +1866,7 @@ After all values have been stacked from zero, an optional **offset** can be appl | |||
- *expand* (or *normalize*) - rescale each stack to fill [0, 1] | |||
- *center* (or *silhouette*) - align the centers of all stacks | |||
- *wiggle* - translate stacks to minimize apparent movement | |||
- a function that receives as arguments a nested index of stacks, the X1 and X2 arrays (resp. Y1 and Y2 for stackY), and Z, and can modify X1 and X2, typically by subtracting the same offset from each of the X1 and X2 values that pertain to a stack. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d like this bulleted list to fit on one line. Can you use a short description here, and move the longer description to the paragraph below that talks about offsets? E.g., “If offset is a function, blah blah blah.” We use this style elsewhere in the README if you want to find precedent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this.
I also wonder if we should have a diverging offset, where the z channel is defined as -2, -1, 0, 1, 2, etc. values, and then you can set the order to z, too, and not need any custom code to do this.
Yes this could be another possibility, but we'd have to pass z independently of fill (which would still be the labels for the color scale), and it might be hard to pass more than one neutral z (since there's only one zero—or maybe two if we check the sign of -0 ;-) ). |
I wonder if allowing the user to mutate values in-place is the correct API here. Maybe when it's a function we want them to return [X1, X2]? |
I had the same thought. For precedent, you could take a look at the map transform: when the map is implemented a function, it returns an array of values: Line 60 in 66142e2
However if the map is implemented a map object with a map method, we use mutation by assigning to the passed Lines 67 to 72 in 66142e2
Also d3-shape’s stack.offset uses mutation: https://github.com/d3/d3-shape/blob/main/README.md#stack_offset I think mutation is fine here, mostly because it feels like a pretty low-level API already given the arguments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I refactored the example to make it easier to reuse this technique. (I expect in the future we could make these even easier with a new option for the stack transform, but this is fine for now.)
I also switched the dataset to CSV and added attribution.
use case: diverging semantic bars following a Likert scale
see https://talk.observablehq.com/t/diverging-stacked-bar-chart-in-plot/6028