Update ComponentChild types #4432
Conversation
The type `object` is pretty wide and does not follow ReactNode types, so this change is to reflect the type from React.
|
Looks like this breaks a few TS tests.
For what it's worth, we don't aim to match React's types in core necessarily, only in compat, and even that is more about avoiding conflict than matching in strictness. We're different frameworks with different implementations, we do accept different types in some circumstances. |
Fair enough, for the failed tests the issue is when passing functions as children in components (that is found in Context.Consumer). I have uploaded a fix for that so the tests should be passing. |
src/index.d.ts
Outdated
| | string | ||
| | number | ||
| | Iterable<ComponentChild> |
There was a problem hiding this comment.
I don't think we support any iterables as component children. Can't find code in our source that explicitly invokes the iterator protocol.
There was a problem hiding this comment.
So do you think is better the Array type here?
| export type ComponentChild = | ||
| | VNode<any> | ||
| | object | ||
| | string | ||
| | number | ||
| | Array<ComponentChild> | ||
| | bigint | ||
| | boolean | ||
| | null | ||
| | undefined; | ||
| | undefined | ||
| | Function; | ||
| export type ComponentChildren = ComponentChild[] | ComponentChild; |
There was a problem hiding this comment.
I wonder, do we really need to alter the type here? I do generally prefer ComponentChild being singular, with ComponentChildren being used if an array of children is needed.
If it's a compat issue, we can simply alter the ReactNode type instead?
There was a problem hiding this comment.
looks kinda weird - with this change, ComponentChild and ComponentChildren are the same type...
The
objecttype is pretty wide and does not follow ReactNode types, so this change is to reflect the type from React.Follows #1116