Normalize usage of types ReactNode and ReactNodeLike

[cuppajoey]

Package

@carbon/react

Browser

No response

Package version

v1.53.0

React version

v16.140

Description

The types defined for TextArea.labelText and TextInput.labelText do not match. The former is typed as prop-types.ReactNodeLike while the latter is typed as React.ReactNode. In older versions of React, ReactNode included support for {}, but has since been removed. Consumers who haven't yet upgraded to React 18 can experience type errors (as demonstrated in the included StackBlitz demo) between two props which should accept the same data types.

---

While this issue can be worked around, I wanted to take this opportunity to highlight an inconsistent practice when writing types for props that accept a ReactNode. Currently many component props accept ReactNode while others accept ReactNodeLike, e.g., TextArea and TextInput. In some cases both types are being used within the same component (TextInput.labelText vs TextInput.slug).

From my understanding, ReactNodeLike is meant to match ReactNode without being dependent on React itself (See DefinitelyTyped/DefinitelyTyped#29194). However, since @carbon/react has a direct dependency on react, we should use ReactNode exclusively instead of relying on two packages for what is essentially the same type definition.

If the maintainers agree, I'm happy to contribute a fix for this myself 👍.

All the components that have the intertwining between the typescript interface and type annotations from the prop-types library:

Tasks

Preview Give feedback

1. Checkbox #16449
   area: typescript role: dev 🤖 type: bug 🐛 +3
   
2. ComboBox #16481
   area: typescript role: dev 🤖 severity: 3 +3
   
3. ComposedModal #16450
   area: typescript role: dev 🤖 type: bug 🐛 +3
   
4. TableHeader #16451
   area: typescript role: dev 🤖 severity: 3 type: bug 🐛 +4
   
5. TableSlugRow #16452
   area: typescript role: dev 🤖 severity: 3 type: bug 🐛 +4
   
6. DatePicker #16459
   area: typescript role: dev 🤖 type: bug 🐛 +3
   
7. DatePickerInput #16460
   area: typescript role: dev 🤖 type: bug 🐛 +3
   
8. DropDown #16461
   area: typescript role: dev 🤖 type: bug 🐛 +3
   
9. IconButton #16462
   area: typescript role: dev 🤖 type: bug 🐛 +3
   
10. Modal #16463
    area: typescript role: dev 🤖 severity: 3 type: bug 🐛 +4
    
11. Multiselect #16464
    area: typescript role: dev 🤖 type: bug 🐛 +3
    
12. Normalize using ReactNode for types in NumberInput #16410
    component: number-input severity: 3 +2
    
13. Normalize using ReactNode for types in RadioButton #16411
    component: number-input severity: 3 +2
    
14. Normalize using ReactNode for types in RadioButtonGroup #16412
    component: radio-button severity: 3 +2
    
15. Normalize using ReactNode for types in Select #16414
    component: select severity: 3 +2
    
16. Normalize using ReactNode for types in Slider #16416
    component: slider severity: 3 +2
    
17. Normalize using ReactNode for types in DismissableTag #16417
    component: tags severity: 3 +2
    
18. Normalize using ReactNode for typescript types in OperationalTag #16419
    component: tags severity: 3 +2
    
19. Normalize using ReactNode for typescript types in SelectableTag #16420
    component: tags severity: 3 +2
    
20. Normalize using ReactNode for typescript types in Tag #16421
    component: tags severity: 3 +2
    
21. Normalize using ReactNode for typescript types in Text #16422
    severity: 3 +1
    
22. Normalize usage of ReactNode for typescript types in TextArea #16423
    component: text-area severity: 3 +2
    
23. Normalize using ReactNode for typescript types in PasswordInput #16424
    component: password-input severity: 3 +2
    
24. Normalize using ReactNode for typescript types in TextInput #16425
    component: text-input severity: 3 +2
    
25. Normalize using ReactNode for typescript types in Tile #16426
    component: tile severity: 3 +2
    
26. Normalize using ReactNode for typescript types in TileGroup #16427
    component: tile severity: 3 +2
27. Normalize using ReactNode for typescript types in FilterableMultiSelect #16480
    area: typescript role: dev 🤖 severity: 3 +3
    

You can take up each component as a separate issue and work on it.

Reproduction/example

https://stackblitz.com/edit/github-bcs3rp?file=src%2FInput.tsx

Steps to reproduce

1. Wait for the application to start and for Typescript to load.
2. Open src/Input.tsx.
3. Hover over labelText in the TextArea on line 12.

Suggested Severity

None

Application/PAL

No response

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[tay1orjones]

Thanks for opening this up. The mismatch here should definitely be fixed. Which way to fix it I'm unsure on. We state support for react 16, 17, and 18. It sounds like using ReactNode might cause typescript errors for 17 and 18 users in certain scenarios. Avoiding using prop-types within TypeScript interfaces seems reasonable despite the downsides.

I'm not opposed to consolidating on using ReactNode for now, and we'll keep an eye on feedback if it's problematic.

[cuppajoey]

Thanks for opening this up. The mismatch here should definitely be fixed. Which way to fix it I'm unsure on. We state support for react 16, 17, and 18. It sounds like using ReactNode might cause typescript errors for 17 and 18 users in certain scenarios. Avoiding using prop-types within TypeScript interfaces seems reasonable despite the downsides.

Could you point me to some info regarding the potential errors with ReactNode with 17 and 18 users?

I'm not opposed to consolidating on using ReactNode for now, and we'll keep an eye on feedback if it's problematic.

Are you open to contributions on this? We could consolidate these incrementally as we work on other issues.

[tay1orjones]

@cuppajoey Yes here's one example from slack

Are you open to contributions on this?

Yes absolutely, we can do them incrementally as we work on other stuff. @Gururajj77 could you add a list here of all components that need to be modified?

[2nikhiltom]

Hey ! All the components are covered via following PR's #16453, #16465, #16418, #16428 and #16449