Export component prop types

[valtism]

What package within Headless UI are you using?

@headlessui/react

What version of that package are you using?

v1.5.0

What browser are you using?

N/A

Reproduction URL

N/A

Describe your issue

In React + Typescript, a common pattern I follow is to wrap a library component for styling or custom behaviour before exposing it to the rest of the codebase. I like to mirror the underlying component props so that Typescript intellisense can provide the same prop hints to for the wrapper component as the underlying library component.

Here is an example of what I want:

// Wrapping a tab for custom styling. TabProps, however, does not exist;
function TemplateLibraryTab({ children, ...props }: TabProps) {
  return (
    <Tab
      {...props}
      className={({ selected }) =>
        clsx("p-2 rounded", selected ? "text-gray-900" : "text-gray-500")
      }
    >
      {children}
    </Tab>
  )
}

HeadlessUI does not seem to expose these props, or at least I could not find them. Would it be possible to export these prop types for this purpose? I think it is a strong use-case.

[valtism]

I should point out that there is a workaround for this. You can use React.ComponentProps to pull out the type from the component.

function TemplateLibraryTab({ children, ...props }: React.ComponentProps<typeof Tab>) {
  return (
    <Tab
      {...props}
      className={({ selected }) =>
        clsx("p-2 rounded", selected ? "text-gray-900" : "text-gray-500")
      }
    >
      {children}
    </Tab>
  )
}

This works in this use-case, but I have run into issues with it in the past. I still think that exporting prop types like other libraries is a good thing to have.

[easga]

I have been doing React.ComponentProps for exactly the same use case (I wrap all the components I import) and it worked very well so far! However v1.6.0 breaks this for me. Would love to know if there is a workaround at least, otherwise will stay with v1.5.

[ZerNico]

I have been doing React.ComponentProps for exactly the same use case (I wrap all the components I import) and it worked very well so far! However v1.6.0 breaks this for me. Would love to know if there is a workaround at least, otherwise will stay with v1.5.

Yup for some reason it broke now.

Type '(<TTag extends ElementType<any> = "button">(props: Props<TTag, TabRenderPropArg, TabPropsWeControl>, ref: Ref<HTMLElement>) => ReactElement<...>) & { ...; } & { ...; }' does not satisfy the constraint 'keyof IntrinsicElements | JSXElementConstructor<any>'. Type '(<TTag extends ElementType<any> = "button">(props: Props<TTag, TabRenderPropArg, TabPropsWeControl>, ref: Ref<HTMLElement>) => ReactElement<...>) & { ...; } & { ...; }' is not assignable to type '(props: any) => ReactElement<any, any>'.

Exporting the PropTypes would probably still be the nicer solution.

[CapitaineToinon]

Thanks to discussions/601, I got it working like this:

import { ComponentType } from 'react'
import { Dialog as HeadlessDialog } from '@headlessui/react'

type ExtractProps<T> = T extends ComponentType<infer P> ? P : T

function DialogRoot(props: ExtractProps<typeof HeadlessDialog>) {
  // add your own logic here
  return <HeadlessDialog {...props} />
}

You may also need to do something like this if you want the nested components to work too.

export let Dialog = Object.assign(DialogRoot, {
	Backdrop: HeadlessDialog.Backdrop,
	Panel: HeadlessDialog.Panel,
	Overlay: HeadlessDialog.Overlay,
	Title: HeadlessDialog.Title,
	Description: HeadlessDialog.Description,
})

[merlinaudio]

Broken in 1.6.1 for me too! Would greatly appreciate a fix 🙂

[Bohemus307]

Same here with 1.4.3. Would love a fix thats less confusing.

[babycourageous]

Thanks @CapitaineToinon - i was using the original React.ComponentProps<typeof Tab> method and after upgrading to 1.6.5 ran into the length TS error above. Your new workaround worked wonders!

[shftlvch]

Plus to exporting prop types, thnx @CapitaineToinon for workaround.

[JaapWeijland]

+1 to exporting prop types, I'd like to use ComponentProps<typeof Dialog> like I would with all other components

[erickreutz]

+1 creating components with any sort of extensibility using headless + typescript has been a headache for me.

[flammenmensch]

Since headless components are declared more as pure functions, it seems that it is now possible to extract the props using the Parameters type:

type MyPopoverButtonProps = Parameters<typeof HeadlessPopover.Button>[0];

Note the [0] at the and, since the function takes two arguments: props and ref.

For more advanced cases you can add generics:

type HeadlessUIProps = keyof JSX.IntrinsicElements | React.JSXElementConstructor<any>;

type MyPopoverProps<T extends HeadlessUIProps> = Parameters<typeof HeadlessPopover<T>>[0];

[Mando75]

Using Parameters<> works for some of the simple components, but it runs into issues with more complex prop configurations in components like Combobox.
For example, Combobox's value prop can either be a single value, or an array of values. The expected TS type for the value is determined by whether the multiple prop is set to true or false.

If you use the Parameters approach, TS starts to run into problems because it doesn't know which overload to use for the expected props. The combobox type declarations list the possible permutations, but there is no way to specify which permutation you want to use via Parameters

This is because the only available export is typeof ComboboxFn (which includes all possible permutations)

This means that if you try to do something like the following:

interface Option { foo: string } 

// accept all but the multiple prop
type ComboboxProps<TOption extends Option> = Omit<
  Parameters<typeof Combobox<TOption, React.ElementType<HTMLDivElement>>>[0],
  'multiple'
>;

type MyComboboxProps<TOption extends Option> = ComboboxProps<TOption> & { myProp: string }

function MyComboboxWrapper<TOption extends Option>({value, onChange}: MyComboboxProps<TOption>) {
  // value and onChange have multiple conflicting implementations 
}

you will get TS errors due to the conflicting implementations.

If someone has discovered a better solution for this situations like this, I would love to hear it. I would still advocate simply exporting the Prop types so we don't need to find complex workarounds for something that should be fairly simple. I haven't seen a reason in this thread for why this couldn't be done, only workarounds which don't seem to be stable as the library is evolving. Scanning through the source, it seems like the prop types are declared for most of the components, so I feel like it should be simple enough to add the export keyword to them. I would be willing to open a PR to do this if the maintainers are not opposed to it. I would like to hear from them first before starting work on it.

[itsmingjie]

+1 on this, would be extremely useful for custom-styled components in a design system where we do not want developers to directly use headless-ui components.