You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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?
Duplicates
Latest version
Summary 💡
In production builds of the application
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.
The text was updated successfully, but these errors were encountered: