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
React generates an automatic 'name' for components based on the class name or function name of the render function for hook-based components. However, React.forwardRef prevents this being done successfully. When hook-based components use React.forwardRef it is helpful to set a displayName field on the result so that the component shows up recognisably in dev tools and debugging etc.
Some components do set displayName, e.g.Button, but others do not, e.g.TextInput.
The deprecateFieldOnObject function added in #9008 by @tay1orjones relies on displayName to be set in order to produce a useful message. If a Carbon user currently uses the now-deprecated form TextInput.PasswordInput, they receive the following warning message: "Warning: The PasswordInput field has been deprecated on the undefined object. Please import and use the field directly." The word "undefined" appears in that message because TextInput does not currently have displayName set on it.
Is this issue related to a specific component?
Yes, quite a lot of them. The following components DO have a displayName set currently. All the other components would be candidates to have displayName set on them.
Breadcrumb
BreadcrumbItem
Button
ButtonSet
Checkbox
TableHeader
TableToolbarAction
Dropdown
InlineCheckbox
InlineLoading
ListBox
ListBoxMenu
MultiSelect
NumberInput
OverflowMenu
RadioButton
Select
Switch
TextArea
Tooltip
HeaderGlobalAction
HeaderMenu
HeaderPanel
SideNavMenu
Only two components currently use deprecateFieldOnObject, and they are:
MultiSelect -- this has displayName set
TextInput -- this does not
What did you expect to happen? What happened instead? What would you like to
see changed?
At least TextInput should have a displayName set so that the deprecation message is shown correctly. Some thought should then be given as to whether some other, or maybe all other, components should have displayName set systematically.
What browser are you working in?
n/a
What version of the Carbon Design System are you using?
10.41.0
The text was updated successfully, but these errors were encountered:
@dcwarwick I believe the helper uses Component.name as a fallback but that components that use React.forwardRef won't have a name defined (or displayName). Definitely makes sense to add in displayName for components that use forwardRef and this helper 👍
What package(s) are you using?
carbon-components
carbon-components-react
Detailed description
React generates an automatic 'name' for components based on the class name or function name of the render function for hook-based components. However,
React.forwardRef
prevents this being done successfully. When hook-based components useReact.forwardRef
it is helpful to set adisplayName
field on the result so that the component shows up recognisably in dev tools and debugging etc.Some components do set
displayName
, e.g.Button
, but others do not, e.g.TextInput
.The
deprecateFieldOnObject
function added in #9008 by @tay1orjones relies ondisplayName
to be set in order to produce a useful message. If a Carbon user currently uses the now-deprecated formTextInput.PasswordInput
, they receive the following warning message: "Warning: The PasswordInput field has been deprecated on the undefined object. Please import and use the field directly." The word "undefined" appears in that message becauseTextInput
does not currently havedisplayName
set on it.Yes, quite a lot of them. The following components DO have a
displayName
set currently. All the other components would be candidates to havedisplayName
set on them.Only two components currently use
deprecateFieldOnObject
, and they are:displayName
setAt least
TextInput
should have adisplayName
set so that the deprecation message is shown correctly. Some thought should then be given as to whether some other, or maybe all other, components should havedisplayName
set systematically.n/a
10.41.0
The text was updated successfully, but these errors were encountered: