[displayName] questioning if its still needed

[Andarist]

When its used:

• error messages
• dev tools
• HOCs

I would argue that its valuable only in DEV mode. Even when it comes to error messages I think I've never seen any production log containing it, I cannot be sure though if it never is.

And if its valuable only in DEV mode, shouldnt we just ditch adding them (or write a ditching transform/codemod) as they can be inferred from the functions/classes/variables anyway? The only remaining use case would be using displayName for HOCs.

If Im wrong let me know. This would however fix 2 minor problems:

• smaller build outputs (slightly)
• remove problem of unintentionally preventing tree-shaking of SFCs in flat bundles (more can be read here)

[gaearon]

shouldnt we just ditch adding them (or write a ditching transform/codemod) as they can be inferred from the functions/classes/variables anyway?

AFAIK we aren't adding displayName explicitly anywhere—I recommend that you don't either. Indeed they're inferred from ES6 functions/classes.

[Andarist]

Thanks for a quick answer, it was a habit I've developed and didnt quite question it till today.

Also got impression that its added in the React's docs - which is not true. However some displayNames are still floating around, i.e. here.

[gaearon]

It’s not really a big deal in React Redux, there's like two components there 😛 . For libraries with 100s of components I would definitely not recommend this pattern but in this case it hardly matters.

[Andarist]

Yeah, it surely doesnt matter code-wise, but keeping this 'legacy' in such popular library kinda gives a wrong example and somebody might use it without real need in other project