Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
add 'width' to box and violin trace #3109
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
add 'width' to box and violin trace #3109
Changes from 2 commits
8f04d13
f76ca97
81cdbe9
5ef2eeb
1c6b26b
2d93a0e
1f9ced8
26f44c4
77b9c9d
243a369
eb5e9da
eea273b
408aacb
0555283
4eb8b44
44e0a88
f8b963b
54aa355
0d4239b
fa3a314
c63780f
c24330d
6e7883d
37786d6
45ae47d
8366c88
ce81377
8885b5e
57cc05a
fe3d7ed
44fa269
f5ba38c
34722d3
d1aed48
c70f7d5
0dea0e9
5e5f9ee
d04c60c
91497e5
657848f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
⚡ that
,
Not sure why our linting didn't pick this up.
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 added this as I placed the width property at the end of this list the first time around. I then moved to the middle to a more appropriate spot but forgot to ⚡️ the
,
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 might just set the
dflt
to0
and have that mean "auto". That's a convention we use various other places. Then you can (still) use truthiness testif(trace.width)
to tell if the user has specified an explicit width.BTW this is in
box/attributes
and you have explicitly disabled this for boxes below but I'm sure you'll enable it in a revision 😁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.
(also this is in
box/attributes
but thedescription
below says violins...)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.
Hmm. Bar
width
hasdflt: null
which I think is more appropriateplotly.js/src/traces/bar/attributes.js
Lines 155 to 165 in 7ae6fd6
Which "other places" are you referring to?
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 was thinking of
nticks
,nbins(x|y)
, also looks like we do that formaxdisplayed
.null
is certainly more meaningful on its own than0
, and it's necessary if0
is a valid value distinct from "auto" - likebar.offset
where0
means "center the bar at the data value" and "auto" means "if the bars are grouped, offset them all so they end up side-by-side".It's just a little funny though with
valType: 'number'
- it meansnull
looks invalid, so if you try and set it we'll determine it to be invalid and fall back on the default, which I guess is fine as long asnull
is the default, but it would still failPlotly.validate
. Also you can't set it at all viarestyle/relayout
, becausenull
there means "unset" - again, not immediately a problem as long as this is the default. BUT... what if you have a template that overrides the default? Seems to me then you would be unable to revert to auto with any setting at all of the user attribute, right?valType: 'angle'
adds a special value'auto'
, which might be the best of both worlds? Its meaning is clear (and distinct from0
), and it's not intercepted by plotlyjs likenull
is. Perhaps we should allowvalType: 'number'
to specifyallowAuto: 'true'
, orextras: ['auto']
?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.
Interesting point. This is somewhat related to #2834, I'll comment over there.
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 suspect we should disable
scalegroup
andscalemode
if there's awidth
... otherwise it would be very confusing what should happen. That would look like: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.
scalegroup
andscalecount
seem to not do anything when there iswidth
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.
Exactly, that's why we don't want to
coerce
them - every attribute that makes it totraceOut
should do something.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.
Oh sorry, I marked this resolved when I saw that you added the conditional
coerce
block... but I guess you removed it again in a later commit. We do want the conditional, per my previous comment.