ParentComponent equivalent of SolidJs in TSRX

[Borderliner]

SolidJs has a ParentComponent that has { children?: JSX.Element } attribute by default. TSRX has no way of distinguishing between a Component and a ParentComponent. Take this as an example:

// Regular SolidJS TSX
type RootProps = ComponentProps<typeof KTabs>

const Root: ParentComponent<RootProps> = (props) => {
  const [local, others] = splitProps(props, ['class', 'children', 'orientation'])

  return (
    <KTabs
      class={cn(
        'flex gap-3',
        local.orientation === 'vertical' ? 'flex-row items-start' : 'flex-col',
        'data-disabled:opacity-60',
        local.class
      )}
      orientation={local.orientation}
      {...others}
    >
      {local.children}
    </KTabs>
  )
}

Here, the local.children is properly typed as children?: JSX.Element. But for TSRX to work, I have to manually add children to props:

type RootProps = ComponentProps<typeof KTabs> & { children?: JSX.Element }

component Root(&{ class: className, children, orientation, ...others }: RootProps) {
    <KTabs
      class={cn(
        'flex gap-3',
        orientation === 'vertical' ? 'flex-row items-start' : 'flex-col',
        'data-disabled:opacity-60',
        className
      )}
      {orientation}
      {...others}
    >
      {children}
    </KTabs>
}

Now children is properly typed as children?: JSX.Element. It's kinda ugly though. Also casting class: className every time is less than ideal.
Is there any other way of doing these?

[ther12k]

Ripple doesn't have a dedicated ParentComponent alias, but you don't need to spell out children?: JSX.Element by hand either. The built-in helper you want is PropsWithChildrenOptional, and the child type should be Ripple's Children, not JSX.Element.

1. PropsWithChildrenOptional<T> is the closest ParentComponent<T> equivalent

Ripple exports these from the ripple entry:

export type Children = TSRXElement | Component | string | number | boolean | null | undefined;

export type PropsWithChildren<T extends object = {}> = Expand<
  Omit<T, 'children'> & { children: Children }
>;

export type PropsWithChildrenOptional<T extends object = {}> = Expand<
  Omit<T, 'children'> & { children?: Children }
>;

So if your base props are currently:

type RootBaseProps = ComponentProps<typeof KTabs>;

then the Ripple version would be:

import type { PropsWithChildrenOptional } from 'ripple';

type RootProps = PropsWithChildrenOptional<RootBaseProps>;

That gives you children?: Children without manually appending { children?: JSX.Element } everywhere.

If you want required children instead, use PropsWithChildren<RootBaseProps>.

2. Use Children, not JSX.Element

JSX.Element is too narrow for Ripple children. The docs use:

import type { Children } from 'ripple';

function Card(props: { children: Children }) {
  return <div class="card">{props.children}</div>;
}

Children covers TSRX elements, components, primitives, null, and undefined, which is closer to what can actually be passed between component tags.

3. Modern Ripple components are plain functions

The current docs define components as ordinary TypeScript functions:

function Root({ children }: RootProps) {
  return <KTabs>{children}</KTabs>;
}

So I'd avoid leaning on the older component Root(...) form for new code.

4. About class: className

You still need to rename class if you destructure it and then reference it in the function body — that's a TypeScript destructuring limitation because class is a keyword-ish property name in this context.

But you can reduce the cn() noise because Ripple's class attribute accepts arrays/objects directly:

function Root({ class: className, children, orientation, ...others }: RootProps) {
  return (
    <KTabs
      class={[
        'flex gap-3',
        orientation === 'vertical' ? 'flex-row items-start' : 'flex-col',
        'data-disabled:opacity-60',
        className,
      ]}
      orientation={orientation}
      {...others}
    >
      {children}
    </KTabs>
  );
}

Truthy entries are included and falsy entries are dropped, so cn()/clsx is usually unnecessary.

TL;DR

import type { PropsWithChildrenOptional } from 'ripple';

type RootProps = PropsWithChildrenOptional<ComponentProps<typeof KTabs>>;

That's the closest Ripple equivalent of Solid's ParentComponent<ComponentProps<typeof KTabs>> today.

A dedicated alias like this would be easy to define locally if you prefer the Solid naming:

import type { Component, PropsWithChildrenOptional } from 'ripple';

type ParentComponent<P extends object = {}> = Component<PropsWithChildrenOptional<P>>;

[leonidaz]

@Borderliner If you're using TSRX with Solid 2.0 as the target framework, you should be able to just use the Solid types.

The syntax that you used for TSRX is no longer correct though as it's just functions now, no component. And to use statements (no return) you need to also have the @{} block.

// TSRX using Solid 2.0

import type { ParentProps, ParentComponent, ComponentProps } from 'solid-js';

type KTabsOwnProps = {
	class?: string;
	orientation?: "horizontal" | "vertical";
	disabled?: boolean;
};

const KTabs: ParentComponent<KTabsOwnProps> = (props) => {
	return (
		<div class={props.class} data-orientation={props.orientation}>
			{props.children}
		</div>
	);
};

type RootProps = ComponentProps<typeof KTabs>;

function Root({
	class: className,
	children,
	orientation = 'horizontal',
	...others
}: ParentProps<RootProps>) @{
	<KTabs
		class={cn(
			'flex gap-3',
			orientation === 'vertical' ? 'flex-row items-start' : 'flex-col',
			'data-disabled:opacity-60',
			className,
		)}
		orientation={orientation}
		{...others}
	>{children}</KTabs>
}

Regarding the Ripple types. They were only created for Ripple and in some frameworks they may not work properly, like React with className.

I'm not sure if we should create these types specifically for TSRX since every framework covers them and you'd be using the framework's api to do your development so I don't think it makes sense to have TSRX specific types.

Happy to reconsider if we get valid reasons for them.

[Borderliner]

Thanks for the info, really appreciate it!