[Improvement] Chart animation: A New Hope

[FabienLelaquais]

📌 Description

Animating traces in Taipy charts is challenging: the data that is sent should reflect the target values, although animating a trace means we need to keep the legacy values, and have Plotly animate from these to the target.

The implementation so far is rather cumbersome and this issue is meant to address that.

I propose that the frontend takes care of this matter, based on these ideas:

• The chart element would have an 'animation' property that describes if and how animation would take place.
• This dictionary, if present, would have several independent properties:
  • 'columns': if present, a string made of ;-separated names of columns to animate, or a list of column names. The default would indicate that all columns are to be animated.
  • 'duration': the speed of the animation (500 ms is I think a relevant default value)
  • 'easing': what easing algorithm is to be used for the animation.

Regarding the implementation side, if 'animation' is present:
When new data comes in, data for all animated columns are temporarily saved in the render session to achieve the animation. The new data is updated with new values to ensure the backend-frontend consistency of column values.
The rendering is performed animating the target traces according to the legacy values (the ones that used to represent data points before the update is done) and the new values.
It might be profitable to use useRef() to store the previous animated data columns.

📜 Code of Conduct

• I have checked the existing issues to avoid duplicates.
• I am willing to work on this issue (optional)

✅ Acceptance Criteria

• The refactored code maintains existing functionality without breaking changes.
• Any new code is covered by unit tests.
• Code coverage remains at least 90%.
• Performance improvements are documented, if applicable.

[FredLL-Avaiga]

Should it really be a dict
or should we have animation_columns, animation_duration, animation_easing ?
Or should we define a python class?

[FabienLelaquais]

I like that all animation parameters are gathered in a single property, and that avoids adding yet a bunch of properties to an element that already has quite a few.
However, if there's a good reason to spread them, so be it. I guess it makes it slightly easier to deal with Effect hooks on the React side. I won't die on this hill.

[FredLL-Avaiga]

How do you like my proposal to define a python class as the property type?

I like that all animation parameters are gathered in a single property, and that avoids adding yet a bunch of properties to an element that already has quite a few.
However, if there's a good reason to spread them, so be it. I guess it makes it slightly easier to deal with Effect hooks on the React side. I won't die on this hill.

[FabienLelaquais]

Oh I do like it.
The only problem I see with that is that it would be the single one place where this occurs.

[FredLL-Avaiga]

Beginning of a new era

Oh I do like it.
The only problem I see with that is that it would be the single one place where this occurs.

[FabienLelaquais]

Now that we discussed this face-to-face, I admit you were right from the get go.
This can improve usability from the programmer's standpoint, clarify the doc, and simplify future extensions as well.

Please go for it - replacing the hack for the Plotly figures in the process.

Thanks!