You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Narrative component has highlighted issues in how we call phylotree methods in order to update the tree. Currently we have a system where we compare old vs new props (react-like pattern) in TreeView, identify the salient changes and call the appropriate PhyloTree methods. (Phylotree also stores it's own state.) This works ok for current user interactions, but when too many changes are present the D3 methods don't perform as expected (my guess is that there are too many being called and they are called too quickly after one another and the transitions are colliding).
Proposal:
Store copies of relevant state (react.props) PhyloTree. The PhyloTree state dictates what is drawn. TreeView can therefore compare (new) redux state with D3 state and call the appropriate D3 methods (each methods updating the relevent PhyloTree state).
This removes the reliance on comparing old props to new props and allows batching of updates (i.e. update the tree on a "tick" cycle instead of every time the reducers have changed). This should have positive performance implications for the animation.
The tick-like cycle of D3 updates should prevent bugs where a D3 function fires before the previous one has completed.
This should remove cases of react & phylotree being "out of sync" as we are comparing "current D3 state (what is drawn)" to "current redux state (what should be drawn)", rather than having to capture every incremental change to props.
When there are too many differences, simply re-render the tree (like bf3bc4a) rather than trying to update certain aspects.
@colinmegill can you please advise us whether this is a good idea.
The text was updated successfully, but these errors were encountered:
not sure how to best do this. A while back we discussed whether we should make PhyloTree stateless and trigger all updates from upstream. But this has been dormant for a while
I am in favor of keeping phylotree as stand-alone as possible, which is why I am trying to go the route of maintaining "state" in phylotree, comparing react state to that, and firing the necessary changes. I can't see how we avoid maintaining some state in phylotree (e.g. divergence or temporal?). I forgot that repo existed - i'll have a browse.
Re: transition collisions, how about maintaining a workInProgress flag and toggling it off like so:
The
Narrative
component has highlighted issues in how we call phylotree methods in order to update the tree. Currently we have a system where we compare old vs new props (react-like pattern) inTreeView
, identify the salient changes and call the appropriatePhyloTree
methods. (Phylotree
also stores it's own state.) This works ok for current user interactions, but when too many changes are present the D3 methods don't perform as expected (my guess is that there are too many being called and they are called too quickly after one another and the transitions are colliding).Proposal:
PhyloTree
. The PhyloTree state dictates what is drawn.TreeView
can therefore compare (new) redux state with D3 state and call the appropriate D3 methods (each methods updating the relevent PhyloTree state).@colinmegill can you please advise us whether this is a good idea.
The text was updated successfully, but these errors were encountered: