Refactor VictoryTransition and animations #2104
Labels
Issue: Accepted
The submitted issue has been confirmed by the Victory core team
Status: On Hold ⚠️
This issue has prerequisites before it can be addressed
Type: Enhancement ✏️
An enhancement or feature proposal that will be addressed after the next release
Milestone
This is a larger issue designed to cover a few individual bugs and issues that have been raised around Victory transitions. I'm just linking to all of the issues here since there have been a lot of issues around this recently, and I'm trying to prioritize our issues and cut down on some of the duplicates. Before these can be addressed, we should consider refactoring
victory-transition.js
and overhauling how transitions and animations are handled.I am currently marking this as on hold until we can have more discussions about how we want to break up this work.
Issues to address:
Technical notes:
Because of the performance concerns around re-rendering every React component many times during each transition state, it might be a good idea to consider a d3-based approach that mutates the DOM without re-rendering every React component. In her d3 + React course, Shirley Wu discusses the division of responsibilities between React and d3, and the advantages of allowing d3 to control DOM rendering in some specific circumstances, such as during transitions. use-d3-transition is an example of how we might cede this responsibility to d3 instead of React to simplify our code and reduce React re-rendering cycles.
The text was updated successfully, but these errors were encountered: