-
-
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
Adding the ability to specify the tail of an annotation arrow in abso… #610
Conversation
…lute point in grid terms rather than relative pixel offset terms.
…lute point in grid terms rather than relative pixel offset terms. This is useful for the specification of trendlines which will continue to show the correct trend when the chart is zoomed in or out.
# Conflicts: # src/components/annotations/attributes.js
…lute point in grid terms rather than relative pixel offset terms. Squashing commits
…lute point in grid terms rather than relative pixel offset terms.
…to the time I'm spending trying to figure out why they are breaking everything else.
So it looks like my unit tests were responsible though I have a difficult time understanding how. For now, I've just removed them as they were of dubious value as it was and I don't have time to keep investigating. If you can quickly see what I was messing up, i'll fix it and add it back. |
You can see the output of the tests here. One test result - |
Yeah thanks the timezone one i saw and was going to fix if not for the other ones. It was the all of the supplyLayoutDefaults failures which i didn't understand. The diff between them passing and failing was just me removing my unit tests (no source code changes). I'm not a jasmine/plotly expert and I don't understand why my unit tests would cause most of the other tests to fail. Very specifically it was this require: if i put that in, all of the tests fail and if i remove it, they all pass (except of course the annotation ones). Now I looked at some other tests and tried adding thanks for helping me with this! I look forward to continuing to contribute. |
Thanks for the contribution! Regarding the tests - they do run in the same "space" in the browser, so it is possible to have conflicts across files if the tests leak. This gets a 💃 from me, but I'll wait for @etpinard to give it a pass over before merging it in. |
dflt: false, | ||
role: 'style', | ||
description: [ | ||
'Indicates if the tail of this arrow is a point in ', |
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.
Wouldn't it be better, more customizable and more plotly.js-esque to have this functionality be set with a pair of attributes, one for each axis?
I'm thinking about:
{
axref: 'x', // or 'pixel' (or 'paper' down the road) similar to 'xref' but for the arrow tail
ayref: 'y'
}
@mdfederici But this solution might have too many degrees of freedom for most cases. Can you think of a use case where a user would want the x
arrow coordinates in pixel and the y
in data coordinates (or vice-versa)?
@mdfederici Great PR. This will make a addition to plotly.js. I would be nice to merge some of several The more I think about it the more a like the per-coordinate Regarding the weird jasmine test failure you experiment, |
@etpinard thanks for the review. Regarding the refs, I cannot think of a case where I would use one axis specified in pixels and not the other. In cases like this, I tend to err on the side of YAGNI as long as that path doesn't box me out from implementing said functionality in the future. That being said, you all know your product vision and userbase/use cases much better than I do and i'm happy to implement the refs given that is what you think is right. I'll update the PR later today or tomorrow morning. I echo your sentiments on the refactor. Several times I found myself wanting to do at least a moderate size refactor but decided against it as I didn't want to take on such a large undertaking due to time constraints (and also didn't want to couple the functionality which I desire to it). |
Thanks! |
… Can't figure out how the regex for axis ref works, so hardcoded to x,y for now and seeking guidance.
# Conflicts: # src/components/annotations/attributes.js # src/components/annotations/index.js # test/image/mocks/annotations.json # test/jasmine/tests/annotations_test.js
@etpinard I've switched to axref and ayref and all seems to be working. You'll see though that I hardcoded the acceptable axis values in attributes.js. This is because I haven't figured out how that regex gets coerced to the correct ref. If i have
... and I specify: "ayref": "y" when I coerce for the supplyDefaults, I will get pixel. Any advice for how to do this correctly? thanks. |
arrowY = Lib.constrain(annPosPx.y - options.ay, 1, fullLayout.height - 1); | ||
if(options.axref === options.xref) | ||
arrowX = Lib.constrain(annPosPx.x, 1, fullLayout.width - 1); | ||
else |
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. Please add some { }
.
Either as:
if() {
} else {
}
or
if() {
}
else {
}
But, we allow one-liners like
if() /* */
without braces.
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 no problem. that should be catchable by lint 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.
It should. By we haven't decided on a brace-style yet. Making this rule impossible to implement with eslint at the moment.
Personally, I like the Stroustrup style, but most JS folks like the one-trye-brace-style. Moreover, eslint does not have --fix
support for that rule yet. So implementing this rule would require some (maybe a lot) of line change.
Ideally, we want the coerce So, I suggest copying much of |
… duplication of code per github PR 610
@etpinard i think ready for another review though the copy/paste gives me heartburn :) |
also if this is acceptable, can i convince you to publish to npm or will i need to wait a few weeks? |
The next release |
// and coerce it to that list | ||
axes.coerceARef = function(containerIn, containerOut, gd, axLetter, dflt) { | ||
var axlist = gd._fullLayout._has('gl2d') ? [] : axes.listIds(gd, axLetter), | ||
refAttr = 'a' + axLetter + 'ref', |
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.
nicely done.
sweet. thanks |
@mdfederici I was just making my final review for this PR and I noticed one small bug: The |
…was offscreen even if the tail is in coordinate space and on screen.
@etpinard Good catch thanks. My last commit i think brings it to consistency with the other annotations although I would think that the desired behavior would be to only render the part of the annotation which is within the view (meaning don't draw the half of the arrow which is hanging outside of the graph). I didn't look into implementing that though because i'm unsure if that is how you'd want all annotations to behave and it seems like a big-ish deal change to how annotations draw. LMK what you think. |
Great. That's what I was looking for. |
annotationIsOffscreen = true; | ||
} | ||
|
||
if(annotationIsOffscreen) return; |
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 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 sigh...its happening because its coming up against the edge of the svg-container. In my testing, that didn't happen before the tail exited the chart so i didn't see it. I'm sorry about that. I believe that I've fixed it and I've added an off screen to the test to ensure it stays that way.
…he chart, rather than render off screen when panned. Added corresponding annotation to image test.
arrowY = Lib.constrain(annPosPx.y, 1, fullLayout.height - 1); | ||
//we don't want to constrain if the tail is absolute | ||
//or the slope (which is meaningful) will change. | ||
arrowY = annPosPx.y; |
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.
Beautiful.
@mdfederici Fantastic PR. Thanks for your efforts 🍻 |
@etpinard thanks for bearing with me on this one. the next one will be smoother i think :) |
@mdfederici no worries. You did great! |
…lute point in grid terms rather than relative pixel offset terms. #601