We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation .
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
It is not clear what benefit one gains by using specific Cartesian Chart wrappers such as the AreaChart or the LineChart, when instead all charts can be achieved using the ComposedChart.
Proposal:
Advantages:
Disadvantages:
Open Questions:
The text was updated successfully, but these errors were encountered:
@proke03 @arcthur @ckifer @Yilun-Sun I would love to hear your input. This is a refactoring idea, that could simplify Recharts for an upcoming major release.
Sorry, something went wrong.
I think we should do a deep dive on this on your proposed open questions (I think the second one is SUPER important for type safety/type issues).
Lets look at both open and closed issues related to ComposedChart (since a lot of issues have been closed without a solution) and list out what we know. I would also like to do a performance profile - is ComposedChart slower when used with say Line as opposed to LineChart and Line ?
Line
LineChart
This is a big API change and hence one I wouldn't want to make without careful consideration
Before we spend more time here, I would like to have a few more reference opinions. What do you think? @akamfoad @HHongSeungWoo @andrewangelle @PavelVanecek
I have concerns, but if we can solve those I am all for this.
Mostly:
{Type}Chart
generateCategoricalChart
I believe this decision will be easier for us when we remove unnecessary elements and refactor the code sufficiently. While I fully agree with unifying charts with Cartesian coordinates, it seems that there are too many side effects to proceed without substantial refactoring
I am waiting for a store or context for separating the components
The idea to simplify the API is great. One parent chart component coupled with the individual compose-able elements is a better API. Though, I think the decision should put a lot of weight on if it also makes maintenance and updates easier, and simplifies the architecture.
Does the current Tooltip behavior act the same when you have 1 composed chart + 1 line/scatter/bar/area respectively? (I think currently not) - this needs addressed. Does the Tooltip cursor behave the same (also think not)
Couple of manual tests are showing different tooltip behavior particularly with the cursor
Prevent another generateCategoricalChart situation
+1. That thing is a wild untamed beast ??
We would have to extend the Tooltip first, to allow switching between the two types of behaviour for all chart types. That is certainly a reasonable feature request either way, many users want to only see the value of a single data point / line / dot for a LineChart - I had to implement workarounds multiple times already.
Vice versa, one might want to see multiple scatter values per xAxis in the ScatterChart.
So I suggest we extract a separate task here to extend the Tooltip, and consider that one blocking for this deprecation.
No branches or pull requests