Is this correct? I was under the impression that the children prop is always an array.

Not sure now it's been pointed out... it didn't want to type check correctly without changing children in some form though.

I ended up doing it a similar way to the DT react definitions, if there's a type difference between them there may be a more accurate way of doing it for preact but I'm not sure what it would be

Yep, this is correct. The children prop is always an array at runtime, but for jsx type inference in TS they are only of type array when there are more than one child. Example:

type RenderFn = (type: string) => void;

class Foo extends Component<{children: Array<string | RenderFn>}> {
	render() {
		return <div>{this.props.children}</div>;
	}
}

function Bar() {
  // Type checked as NON-array, because the component has one child.
  return <Foo>{(type) => undefined}</Foo>;
}

function Baz() {
  // Type checked as an Array, because the component has now 2 children
  return <Foo>2{(type) => undefined}</Foo>;
}

@Alexendoo can you change {} to object? That way we'd be consistent with the rest of our typings.

@marvinhagemeister why the use of object here? Taking a look on ReactNode it has the following types:

type ReactNode =
        | ReactElement
        | string
        | number
        | Iterable<ReactNode>
        | ReactPortal
        | boolean
        | null
        | undefined
        | DO_NOT_USE_OR_YOU_WILL_BE_FIRED_EXPERIMENTAL_REACT_NODES[
            keyof DO_NOT_USE_OR_YOU_WILL_BE_FIRED_EXPERIMENTAL_REACT_NODES
        ];

Perhaps we may refactor it like:

type ComponentChild = VNode<any> | string | number | Iterable<ComponentChild> | bigint | boolean | null | undefined

At the time React had an object in its definition also but I do not remember why (this is a 6 year old PR 😅), type definitions could also not refer to themselves like that back then

Yeah pretty old 😅 now that is possible to refer to a type by itself; would you mind if I create a PR to update ComponentChild types? object is pretty wide and we can change it by Iterable<ComponentChild>.

I'm not a maintainer here but I'd say go for it yeah, it'll be more visible place to have the discussion at the very least

Just created the PR, @Alexendoo thank you so much for answering.

Yep, this is correct. The children prop is always an array at runtime, but for jsx type inference in TS they are only of type array when there are more than one child. Example:

type RenderFn = (type: string) => void;

class Foo extends Component<{children: Array<string | RenderFn>}> {
	render() {
		return <div>{this.props.children}</div>;
	}
}

function Bar() {
  // Type checked as NON-array, because the component has one child.
  return <Foo>{(type) => undefined}</Foo>;
}

function Baz() {
  // Type checked as an Array, because the component has now 2 children
  return <Foo>2{(type) => undefined}</Foo>;
}

@Alexendoo can you change {} to object? That way we'd be consistent with the rest of our typings.