-
-
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
Transitions with Plotly.react #3217
Conversation
... which will be used to set transition options during Plotly.react updates.
- to (in next commit) efficiently compute axis range transitions - potentially target axis range react update (like we currently do in relayout)
- temporarily add Plots.transitions2 & Cartesian.transitionAxes2 - call Plots.transition2 from Plotly.react when at one animatable attribute has changed AND 'layout.transition` is set by user - 'redraw' after transition iff not all changed attributer are animatable - handle simultaneous trace + layout updates the same way as Plotly.animate - special handling for 'datarevision' diff'ing
Yes! Super-agree :) |
awesome! is there a prerelease build (on a cdn?) that I can try this out on? I recall that we were creating builds on commits now |
@chriddyp https://17875-45646037-gh.circle-artifacts.com/0/plotly.min.js To find the link: |
In Dash-land, for larger features like this, we usually create pre-releases and share them with the community for a couple of weeks to get feedback. If OK with plotly.js, I'd like to do the same with this PR. I will manage the community and I'll create a pre-release in I'm frequently surprised by what folks end up doing with abstract features like this and it's a nice, low-risk way to test the waters. |
If dash users are made aware of the limitations, mainly: Lines 2547 to 2549 in 1cb0d5f
then yeah I'm ok with it. |
Update from today's meeting: I'll attempt to add a flag that makes trace transitions "win out" over layout transitions. |
If the major use of this is object-constancy (as I believe, although I'm open to other beliefs!) then I'm pretty sure we need to provide a mechanism for the developer to identify the 'objects' that deserve 'constancy'. For example if I have traces A, B and C in one state and I transition to another state with just B and C I would expect A to vanish and B and C to stay, not A to transition to B, B to C and C to vanish, as they might if we used position as a key (is that what we're currently doing?). Should we do this by letting the user specify |
Part of the examples I made ⬆️ https://codepen.io/etpinard/pen/XybjZG?editors=1010 |
Ah the |
Here's an example: https://codepen.io/nicolaskruchten/pen/pQddZm?editors=0010 In this case I would expect the red trace to vanish and the blue trace to translate to where the red one used to be, but I don't think I can express that right now. |
|
OK, so we should evolve this PR a bit to only transition matching- |
Presumably this will work the same way as |
I could live with that. We still need to make my example work tho right? Or
did I do it wrong?
…On Mon, Nov 19, 2018 at 23:20 alexcjohnson ***@***.***> wrote:
Presumably this will work the same way as uirevision #3236
<#3236> - if you don't provide uid,
we assign one that's random at first but stays with traces of the same
index. That machinery is nothing new. So internally we only need to key off
uid, but to the user it looks like "uid if you provide that, index if you
don't"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3217 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMbA1VfVtG1KByHXMFLmsr9ZGegIx5Oks5uw4L4gaJpZM4YPboB>
.
|
Transitions from |
(per verbal conversation: I'm not talking about tweening in/out but rather trace-constancy) |
yeah, getting https://codepen.io/nicolaskruchten/pen/pQddZm?editors=0010 to work shouldn't be too hard. I suspect something is up in the react diffing. https://codepen.io/etpinard/pen/yQpNLM?editors=0010 works ok when the before and after |
Just so we don't forget: animations should track |
- making uid anim:true and allowing uid to be numbers was enough to fix this case.
- should still go through calc (and hence a redraw after the transition) but Scatter.plot can handle this case fine.
Update: the trace "object-constancy" bugs are now fixed:
not much extra logic was needed (see commits 4ef048f, 61ee4e9 and 33a9530 for the details), d3's and the key function in this block here: plotly.js/src/traces/scatter/plot.js Lines 36 to 37 in 05d0759
did the rest. |
@chriddyp can you elaborate on your comment on "transition revision" before we merge this guy in? |
... but make sure to count traces deletion as a "non-animatable" change (to make data-mismatch test still passes).
- to DRY up pan/scroll and axes transition (next commit) annotations/shapes/images redraw calls. - add ax._imgIndices stash (similar to _annIndices/_shapeIndices), to make redrawComponents loop just once over the axis list.
- Plots.transition2 becomes Plots.transitionFromReact - Plots.transition and Plots.transitionFromReact are now simple wrappers around a more general _transition() internal method - transitionAxes2 is now merged into transitionAxes, the "find which axis to edit" logic in now in Plots.transition - transitionAxes now uses Axes.redrawComponents and support xa-only and ya-only edits (new react+transition tests were adapted for this)
- with values 'layout first' and 'traces first' which determines whether the figure's layout OR traces are smoothly transitions during Plotly.react calls that generate a data AND layout diff.
Done in 8ab38be via Example: https://codepen.io/etpinard/pen/jXdLgG With that ⬆️ , I'll tag this PR as |
So... if I delete the "traces first" line, it seems to move and pan simultaneously, which is the ideal, right? I thought that wasn't possible somehow? |
That's way layout transitions (like https://plot.ly/javascript/animations/#animating-the-layout) always do. |
... you can't animate marker color/width during those layout transitions at the moment though. |
Ah I see, the blue/black transition was so subtle I missed it. Adding a size transition as well makes it clearer what the tradeoff is. |
@archmoj is going to review this one. |
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 Great work!
Please find my questions below.
Thanks.
Wonderful feature! Kindly move forward and merge it, possibly after figuring out why one test started to fail on master: |
Thanks for the review. I think the failing test is due to the joyplot PR and the boxpoint hover fix not getting along. I'll fix that later this morning. Nothing to worry! |
resolves #1849 (hopefully).
Transitions (don't call them animations) are coming to
Plotly.react
🎉In this iteration, I opted for a single
transition
option container. For example,gives:
which appears a lot smoother in reality than in that gif.
Here are more examples (taken from https://plot.ly/javascript/animations/ but converted to using
Plotly.react
):In brief to get transitions working with
Plotly.react
, this PR:anim: true
to animatable attributes and picked them off duringreact
diffingPlots.transition
that assumes thatgd._fullData
/gd._fullLayout
is the "new" state (N.B.Plotly.animate
assumes thatgd._fullData
/gd_fullLayout
is the "old" state)Plots.transition
figure out ifredraw
after completion is required from restyle / relayout flagsautorange:true
and altered ranges duringreact
diffing to efficiently compute "layout" transitionsfullLayout
beforefullData
to track animatabledatarevision
changesTODO:
react-plotly.js
anddash
folks+ [ ] @nicolaskruchten
+ [ ] @chriddyp
+ [ ] @alexcjohnson
Plotly.transition
<-->Plotly.transition2
done in: 1ed4e42cc @plotly/plotly_js