-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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 midpoint attr to color scales #3549
Conversation
I've love to get this into 1.45 if it's uncontroversial :) |
I'm still 100% convinced |
At present |
I think we should stick with the current naming convention for right now, and when we do something |
which is? |
|
cmin, cmax, cmid ...? |
ok, but we're planning on changing Does anyone in @plotly/plotly_js have an opinion about this? |
In future when we have That said, if |
And the day we do that, we should change |
Making changes to attributes is never fun. This is exactly what I'm trying to avoid. |
What's the rationale for |
Bring color "axis" attribute closer to |
I would leave the existing |
If you really want to merge this ASAP, sure what can that! Now, are you planning on fixing the tests (we should also add jasmine tests making sure |
I can finish it up, just wanted to get feedback on the approach, make sure I didn't miss anything obvious. |
Mostly as you say it's a pain to change existing attrs, so I think we should plan to leave the existing |
So I'm trying to fix the tests and confused about why the |
plotly.js/src/plots/geo/layout/layout_attributes.js Lines 96 to 102 in 0714286
Thanks for uncovering a pretty embarrassing typo. Switching to Now, for plotly.js/src/traces/scattermapbox/attributes.js Lines 73 to 99 in 0714286
as |
Thanks for looking into it @etpinard ! I'm confused about what the "typo" is in the code you linked above... can you clarify please? |
Oops. Wrong link:
|
Ahhh that makes much more sense, thank you :) |
OK despite best intentions I havent found the time to write tests here unfortunately... could someone in @plotly/plotly_js take over the restyle/relayout tests plz? :) |
Ok. I'll do that this morning. |
valType: 'number', | ||
role: 'info', | ||
dflt: null, | ||
editType: editTypeOverride || 'plot', |
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.
@etpinard I wasn't sure what to put for editType
and impliedEdits
btw so I copied over the settings from max
above... maybe it should match auto
instead? Or be something else? Likely your tests will expose any problems but I just wanted to shine a light here.
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.
Restyle got fixed in 23c1cf0
Is that the behaviour you had in mind?
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 must admit I don't fully grok the various nuances of the types of edits, but the test reads fine at first glance!
@@ -1195,6 +1195,77 @@ describe('Test plot api', function() { | |||
.then(done); | |||
}); | |||
|
|||
it('turns on cauto when cmid is edited', function(done) { |
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.
this is an odd description... cmid
only has effect if cauto
is true, but doesn't turn on cauto
per se, right?
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.
but doesn't turn on
cauto
per se, right?
yes, it has to. If not, restyle(gd, 'marker.cmid', 0)
wouldn't work.
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.
by "not work" here I mean it wouldn't apply that new cmid value when cmin
and cmax
are set.
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.
OK I see what you mean.
if(auto) { | ||
coerce(prefix + cLetter + 'mid'); | ||
} else { | ||
coerce(prefix + cLetter + 'min'); |
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.
this line and the next used to always run, but now only conditionally... might this break anything? I'm not sure about the implication of not calling coerce()
.
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.
No tests are failing because of it.
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.
ok
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.
There is a test failure that mentions coerce
:
Test surface supplyDefaults should coerce 'c' attributes with 'c' values regardless of `'z' if 'c' is present FAILED
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.
Ah good eye.
Well cmin
and cmax
have no effect
plotly.js/src/components/colorscale/calc.js
Lines 31 to 37 in bb1239a
if(auto !== false || min === undefined) { | |
min = Lib.aggNums(Math.min, null, vals); | |
} | |
if(auto !== false || max === undefined) { | |
max = Lib.aggNums(Math.max, null, vals); | |
} |
when cauto
is true.
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'm easy. Like I said, I don't know the impact of calling coerce
and ignoring the attr vs not calling coerce
:)
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.
Calling the behaviour correct and adapting the test in ff67812
@plotly/plotly_js can I get a review for this thing? |
@etpinard - sure, I'll review this. |
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.
Great PR.
I was a bit confused when I was trying to paint a surface elevation using cmid
and cmin
.
Here a codepen.
I thought as described #3509 (comment) the user may try to declare the minimum and middle range. However; it lookscmin
has no effect in the mentioned example when cmid
is defined?
Right, that's the expected behaviour it seems like: plotly.js/src/components/colorscale/attributes.js Lines 171 to 177 in ff67812
|
Then it may be reasonable to modify the description of 'Has no effect when `cmid` is defined.'. |
That's not true. Say you have:
then here |
Nicely done. |
Yes the idea is that if you want to specify two points on the curve they must be min/max... not min/mid or mid/max. Easier to implement and document. The mid doc is a bit indirect in that it says “no effect if auto false” and then the auto doc says “false if min and max are set” but I figure this is still correct/readable. |
Closes #3509
LMK what kinds of extra tests you'd like or if you want me to just modify an existing mock or something, or if I've mangled some of the coercion machinery :)