Support for defaultProps will be removed from function components in a future major release. Use JavaScript default parameters instead. at {Component}

[marco-digennaro]

Using a library that include recharts v2.6.2 i get the following error in the console.

Curve: Support for defaultProps will be removed from function components in a future major release. Use JavaScript default parameters instead. at Curve

the charts are rendered normally thou.

[ckifer]

Thanks, noted! Unfortunately moving away from defaultProps causes unintended bugs due to the way recharts works. But this is known and we're trying to get away from them where we can.

Edit: see solution in 2.x #3615 (comment)

[cdimitroulas]

FYI this also happens for the Tooltip component

[ckifer]

Reference for why this is an issue #3438 (comment)

[ckifer]

@akamfoad all of our functional refactors are going to have this issue. We may have to prepared to handle soon as I'm going to release 2.7. Let me know if you have any thoughts

[akamfoad]

@ckifer
I was always feeling bad about the defaultProps but in my refactors I kept them just in case and to reduce the number of changes.

But I think the sooner we embrace JS default params the better, I see many teams are going in this direction, especially those who use TypeScript, I see that is quite the default practice.

This is not going to break semver if we do it in v2, because we just change how we receive the default values, internally, for the users of the library everything will be the same and the warning goes away. What do you think?

[ckifer]

@akamfoad I totally agree, but we still have the cloneElement issue linked above (#3438 (comment)).

I believe all of the components we have refactored besides Tooltip are safe from that issue so we should be able to move them over

[ckifer]

I believe this list holds those that we cannot touch without fear of breaking things

[akamfoad]

So only those components will cause issue if defaultProps is removed, that another component/function needs to access them, including cloneElement, before the component is initialized.

I'm guessing there is a lot of them, especially those from the list in generateCategoricalChart.

Which means they in fact cause breaking change, when migrated to default params. So we might need to hold off here and revert the Tooltip refactor, that is an easy one.

The warning is shown only for Functional Components with defaultProps, but the default behavior may changes in the future for how this affects components (if I understood the RFC correctly). Which means, its probably for the best to prepare for v3.

[akamfoad]

Btw @ckifer

I think its probably for the best, this might encourage us to have major version (not very soon tho), where we internally do not rely on defaultProps, or cloneElement, instead we use normal JS default params, and renderProps (which is not my personal favorite), or Context API.

This way, the children can both render and subscribe to context's provided by the charts (or a an HoC) parent and render, clutter-free

[ckifer]

Thanks for the thoughts @akamfoad! Yeah I agree - I've been shying away from 3.x because it's a lot of work and there's a lot of breaking changes we need to merge in and document but there hasn't really been any meaningful progress made towards it.

But yes we definitely need to 100% rid ourselves of the cloneElement approach, it's the cause of a lot of issues (but it's also some of the magic of recharts which is why it's tough to remove or at least tough to test once you remove it).

[jocarrd]

Same problem, any solution?

[ckifer]

No solution yet but we're aware of it, thanks

[shohan-pherones]

I also need the solution asap, do your job devs.

[ckifer]

There are no devs that work on this project as a job. Please feel free to contribute.

[zwhitchcox]

Just leaving this here:

const error = console.error;
console.error = (...args: any) => {
  if (/defaultProps/.test(args[0])) return;
  error(...args);
};

[ooanishoo]

zwhitchcox

Hi, is this a temporary fix that we can implement for now?

[zwhitchcox]

@ooanishoo This will just hide the warning, but there's not really anything else you can do until it's fixed upstream anyway.

[wuahi]

Having the same issue. Is there an update on where this might be fixed?

[evanlong0803]

I was just about to ask a question, but I guess I won't. Everyone knows 🤣

[ckifer]

No update really besides some noodling in my head to try to pick a path forwards. If I work on anything at all next it will be this, I just can't make time for it right now as other (life) priorities prevail.

[ckifer]

Risky elements are defined (by me at least 😅 ) as any that are referenced by a call to findAllByType findChildByType and those in the map in generateCategoricalChart (see issue linked above - #3438 (comment)). This comes out to:

1. Cell
2. Brush
3. Tooltip
4. Legend
5. ErrorBar
6. XAxis
7. YAxis
8. ZAxis
9. PolarAngleAxis
10. PolarRadialAxis
11. RadialBar
12. Label
13. LabelList
14. ReferenceDot
15. ReferenceLine
16. ReferenceArea
17. CartesianGrid
18. PolarGrid
19. Customized
20. Any graphical child - Bar, Area, Line, Scatter, Funnel, Pie, Radar, RadialBar

All other components outside of these should be able to be refactored to use default params with relative certainty they won't break things. This makes this issue actionable and means that Text, Curve and any others not on this list can be moved over any time. @nikolasrieble @akamfoad for vis.

If anyone wants to take the changes or the change for one component let me know.

[ckifer]

Text refactored in #3670. Curve is open for contribution as well as any others that may currently have issue

[Danielvandervelden]

Thanks for working on this you guys. Patiently waiting for the eventual fix 🙏

[PaulSinghDev]

@ckifer just wanted to let you know I didn't forget last weekend, I crashed my bicycle (whoops) so wasn't in much of a space to bang it out. I'll have time this weekend to have a look :)

[PaulSinghDev]

@ckifer Just been going through this this morning and noticed it seems as though we have an XAxisContext which is responsible for generating a prop map which is fed to useXAxisOrThrow -- from my understanding this hook is returning the current props for the axis to the XAxis component and the returned value is being fed to the CatesianGrid component.

With all that being said, would a sufficient solution be to update the context or hooks to implement a default props of some sorts? I have had a go at implementing a solution but I think I most likely need a bit of a more detailed mental modal of how the overall parts are playing together as my initial attempt killed the unit tests 👀

[PavelVanecek]

That's correct. The problem is that there are parts of code that read defaultProps directly from DOM, by searching the element tree and then matching displayName. Once those are removed, and the context and hooks is the way to do that, the warning will go away.

…

On Mon, May 6, 2024, 13:37 Paul Singh ***@***.***> wrote: @ckifer <https://github.com/ckifer> Just been going through this this morning and noticed it seems as though we have an XAxisContext which is responsible for generating a prop map which is fed to useXAxisOrThrow -- from my understanding this hook is returning the current props for the axis to the XAxis component and the returned value is being fed to the CatesianGrid component. With all that being said, would a sufficient solution be to update the context or hooks to implement a default props of some sorts? I have had a go at implementing a solution but I think I most likely need a bit of a more detailed mental modal of how the overall parts are playing together as my initial attempt killed the unit tests 👀 — Reply to this email directly, view it on GitHub <#3615 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIMTCUWW65FOKZ73EJA2VDZA4CG3AVCNFSM6AAAAAAY6DGBPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJVGE4DIMZXGQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

[ckifer]

+1, its basically all going to lead back to untangling getAxisMapByAxes which is going to be a relatively large undertaking. I for example, tried to refactor ReferenceLine to use defaultParams, but I can't because then axis generation does not know that my reference line has a yAxisId of 0 and an xAxisId of 0, and then can't act on axis domain in the case that ifOverflow="extendDomain" the domain is supposed to get extended if the reference line is outside of the default domain).

We need to make the connection between reference elements and axis elements in a different way (context and hooks)

[zeroliu]

Thanks for keeping us posted for the progress @ckifer ! Really appreciate it!

I found this thread when testing react 19 beta. Looks like this starts to cause runtime issues in React 19 since defaultProps is removed. https://react.dev/blog/2024/04/25/react-19-upgrade-guide#removed-proptypes-and-defaultprops

[ckifer]

Sure thing!

Right, this is why the warning is logged. We won't be able to support React 19 until we finish this.

Although in 2.x branch we might accept #4542 as version 2.12.8 which would move these components back to classes to get rid of the errors. We could then add react 19 to peerDeps and keep working on 3.x without blocking people from upgrading.

[jukkahuuskonen]

That's correct. The problem is that there are parts of code that read defaultProps directly from DOM, by searching the element tree and then matching displayName. Once those are removed, and the context and hooks is the way to do that, the warning will go away.
…

Could this be taken care of (atleast while waiting for next version) by using a wrapper function, that would get the defaultValues from DOM and either pass props or if they are missing then the defaultValues to the real component?

const RealComponent = (param1, param2) => {
  ...
};

const Wrapper = ({ param1, param2 }) => {
  const defaultValues = useMemo(
    () => ({ param1: getParamFromDom('defParam1'), param2: getParamFromDom('defParam2') }),
    []
  );
  return <RealComponent param1={param1 || defaultValues.param1} param2={param2 || defaultValues.param2 } />;
};

or did I totally misunderstand the problem...

[ckifer]

@jukkahuuskonen I guess when we say dom here we're talking about from react elements, or the virtual dom. The linked PR wraps our current functions in class components which solves the issue. I think that the path forward while waiting

[h0lme3]

Thanks for your work @ckifer ! Will be waiting for your great updates!

[GabeKuslansky]

@ckifer Thank you for your efforts!

[diogotrindadeversion1]

Removing defaultProps do not make any sense by the React team.
defaultProps have been a standard on the documentation for years, always on the main examples. And it helps organizing the code with less nested objects. I believe that defaultProps is a better solution comparing to nesting things with JavaScript.
Lots of libraries will have the same issue, including custom private libraries of components, that does not make sense to refactor everything, just because yes.

So I think that you should one an issue on the React repository.
They have a new compiler, they should use it for optimization, and keep defaultProps alone/working.

[PavelVanecek]

defaultProps will stay on class components. This warning is about defaultProps on functional components.

So we could technically solve this by rewriting everything from functional components to classes. But that also means rewriting all hooks.

[diogotrindadeversion1]

defaultProps will stay on class components. This warning is about defaultProps on functional components.

So we could technically solve this by rewriting everything from functional components to classes. But that also means rewriting all hooks.

That does not make any sense. Using classes is going back in time, and it is an old pattern. We can have functions with defaultProps.
Everybody should have that conversation on the React repository.

[ckifer]

Alpha release - https://www.npmjs.com/package/recharts/v/2.13.0-alpha.0
This BREAKS things in R19 (though they're already broken), shouldn't in R18

Please use this alpha to see if defaultProps warnings are gone (and make sure things are still working as normal in R18 and below). For now, all the function components with issues have been wrapped with classes (while we work on 3.x)

[mmdev73]

Alpha release - https://www.npmjs.com/package/recharts/v/2.13.0-alpha.0 This BREAKS things in R19 (though they're already broken), shouldn't in R18

Please use this alpha to see if defaultProps warnings are gone (and make sure things are still working as normal in R18 and below). For now, all the function components with issues have been wrapped with classes (while we work on 3.x)

Works perfectly with R18, console errors disappear and no broken things found. Great job and thanks a lot.

[ckifer]

Nice! All credit to @eps1lon for the interim solution.

Work still needed for things not to break in R19 so I'll wait for more feedback and see if we can get full support in before resolving this. Thanks everyone.

[ckifer]

https://www.npmjs.com/package/recharts/v/2.13.0-alpha.3
Should have more R19 support if not all of it (minus the need to disregard peerDeps and install react-is@19)

Please test this one as well on all React versions 16.8-19 to see if anyone runs into issues. Thanks! 🚀

[MD-YeakubNabi-Hridoy]

Warning: XAxis: Support for defaultProps will be removed from function components in a future major release. Use JavaScript default parameters instead.
how to fix this

[ckifer]

Try installing the alpha version listed above

[Wallauerr]

@ckifer it worked!
The console error is gone.

[barhouum7]

Hey y'all, I think installing v2.10.2 should fix the warning, so try this:

npm install recharts@2.10.2

[UPDATE]: v2.10.2 was working perfectly in a React version under R18

For React versions above R18, this works perfectly for me npm i recharts@2.13.0-alpha.1

[marcusvinicius0]

Console error is gone, thx a lot for the support!

[ckifer]

I'm going to close this since we have a path forwards to remove the errors

Solution is npm i recharts@alpha
I will post back here again when R19 is out and I can release 2.13.0, that will contain the alpha fixes.

Feel free to continue to report any issues found here (or R19 related here)

Thanks all