TypeScript Omit with StrictReactDOMProps results into empty object
Describe the issue
When using Omit in TypeScript it seems to omit everything. Example:
export interface IconButtonProps extends Omit<React.ComponentProps<typeof html.button>, "children"> {
children: React.ReactElement<IconProps>;
}
This results in IconButtonProps type having the ONLY children, and some stuff from ReactStrictDOMDataProps, but nothing else. Every other prop, coming from html.button is also omitted. When removing the Omit<...> everything works fine.
This is maybe a bug with Flow to TypeScript conversion?
Expected behavior
Omitting props should only omit what is wanted.
Steps to reproduce
- Have react-strict-dom with TypeScript set up.
- Create IconButton.tsx containing the above example code.
- See that the interface only contain
children
Test case
No response
Additional comments
No response
Probably has to do something with ReactStrictDOMDataProps in TypeScript, which is not defined at all. If I define it inside dist/types/StrictReactDOMProps.d.ts, everything works as expected.
I just added:
type ReactStrictDOMDataProps = {}
Just found out that also Stringish is unresolved in TypeScript, which makes totally sense because it's converted from Flow.
I guess both Strinish and ReactStrictDOMDataProps should be interfaces. So that they can be overridden by TypeScript users, e.g. with data-props that are used in their projects.
I think TypeScript has a feature where it ignores any data-* props. It's something the Flow team is considering too. Ignoring ReactStrictDOMDataProps altogether for TypeScript might possible / better. Open to suggestions on how to manage Stringish better too
Yes exactly, TypeScript ignores all props in JSX containing - dashes
@necolas I still think that having these types exported from files gives us the most flexibility. We can override particular files for TS easily that way.
Sure. TS doesn't even need that file though
Can you just strip those types in TS? Replace ReactStrictDOMDataProps with {} and Stringish with string
@necolas Our tooling can only split on a file level, so having those files for TS where they're just aliased to {} and string as @efoken suggested is the easiest path. I'll create a PR so we can consider it with a real example.