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
Running our tests in vitest I came across this issue. One(Several tests are failing in browser mode)test is failing because an error message is not matching:
- Expected #3 "The above error occurred in the <ForwardRef(SelectInput)> component" to be included in
"The above error occurred in the <ForwardRef(SelectInput2)> component:
...
Notice the mismatch between <ForwardRef(SelectInput)> and <ForwardRef(SelectInput2)>. esbuild compiles the source slightly differently, resulting in a different displayName for the component. Besides that, the ForwardRef(...) wrapper is unnecessary information for the user. I propose we set the displayName property to the exported component and turn that error message into
The above error occurred in the <SelectInput> component
regardless of how the compiler transforms or renames the component. We only do this in dev mode to avoid impact on end user bundle size.
What are the requirements?
Error messages in dev mode are deterministic and don't contain unnecessary wrappers in component names.
oliviertassinari
changed the title
[RFC] Set displayName on components in dev mode
[code-infra][RFC] Set displayName on components in dev mode
Oct 8, 2024
What's the problem?
Running our tests in
vitest
I came across this issue.One(Several tests are failing in browser mode) test is failing because an error message is not matching:Notice the mismatch between
<ForwardRef(SelectInput)>
and<ForwardRef(SelectInput2)>
.esbuild
compiles the source slightly differently, resulting in a differentdisplayName
for the component. Besides that, theForwardRef(...)
wrapper is unnecessary information for the user. I propose we set thedisplayName
property to the exported component and turn that error message intoregardless of how the compiler transforms or renames the component. We only do this in dev mode to avoid impact on end user bundle size.
What are the requirements?
Error messages in dev mode are deterministic and don't contain unnecessary wrappers in component names.
What are our options?
Proposed solution
No response
Resources and benchmarks
We're already doing this for wherever we use a context
https://github.com/mui/material-ui/blob/488bdd9c7c24aacafb4f6b00fe28dce18ada5828/packages/mui-material/src/Accordion/AccordionContext.js#L10-L12
Search keywords:
The text was updated successfully, but these errors were encountered: