Skip to content
New issue

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

Identifier for component type in production builds #33053

Open
2 tasks done
kbrueckner opened this issue Jun 7, 2022 · 4 comments
Open
2 tasks done

Identifier for component type in production builds #33053

kbrueckner opened this issue Jun 7, 2022 · 4 comments
Labels
status: expected behavior Does not imply the behavior is intended. Just that we know about it and can't work around it

Comments

@kbrueckner
Copy link

Duplicates

  • I have searched the existing issues

Latest version

  • I have tested the latest version

Summary 💡

In production builds of the application

process.env.NODE_ENV === 'production'

all MUI components are anonymous and do not tell the developer which component was rendered.
I am searching for a solution which help to identify the underlying component such as TextField.

Examples 🌈

No response

Motivation 🔦

I am the author of mui-validate a validation library for MUI components.
To validate inputs the MUI components need to be wrapped with higher order components which need to be able to identify the wrapped childs type i.e. TextField.

A solution could have ben to access the childs displayName but this is stripped out in production builds from your side.

@kbrueckner kbrueckner added the status: waiting for maintainer These issues haven't been looked at yet by a maintainer label Jun 7, 2022
@mnajdova
Copy link
Member

This is expected behavior, it should be stripped. See https://twitter.com/dan_abramov/status/1255233343039340548?lang=da

@mnajdova mnajdova added status: expected behavior Does not imply the behavior is intended. Just that we know about it and can't work around it and removed status: waiting for maintainer These issues haven't been looked at yet by a maintainer labels Jun 10, 2022
@kbrueckner
Copy link
Author

It is not about unexpected behaviour, I am rather more asking for an option to identify the component. It does not necessarily have to be the displayName attribute.

@mnajdova
Copy link
Member

But is there a real use-case for it? It's hard for me to justify shipping additional bytes in production without a clear reason why.

@kbrueckner
Copy link
Author

My use case is described above, when writing HOC I need to know the type of the underlying component.
In general I am with you but we are talking about a few bytes not kilobytes. IMO it is also not good practice to strip away such in my view crucial information.

Nevertheless as I mentioned earlier my request goes back to the need to identify the component. Is there any other way to get that information without having to "send more bytes" or would that be the only solution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: expected behavior Does not imply the behavior is intended. Just that we know about it and can't work around it
Projects
None yet
Development

No branches or pull requests

2 participants