[TS]: Fix Component Props declarations

Pay attention to rules for migration at the end of the issue.

Expected Behavior

Be able to import and extend the <component>Props correctly, bringing the JSX.IntrinsicElements props together.

Actual Behavior

Components have theirs on <component>Props combined with JSX.IntrinsicElements being exported using the declare block. The import of <component>Props doesn’t have all the props defined in the declare block.

References: https://github.com/grommet/grommet/pull/4909 https://github.com/grommet/grommet/issues/4976

Proposed Solution

As discussed in the PR: https://github.com/grommet/grommet/pull/4909, We need to check which components follow the pattern of combining the props on declare blocks. A second item is that many components are defined as React.ComponentClass but can be modified to React.FC.

That being said, we should start refining these declarations following the examples below, where we create and export an extended version of the props instead of removing the actual export:

export interface LayerProps {...}
export type LayerPropsExtended = LayerProps & JSX.IntrinsicElements['div'] 

// React.FC or React.componentClass must be evaluated to see if the change is possible.
// Preference to use React.FC
declare const Layer: React.FC<LayerPropsExtended>;

export { Layer };

// another example
export interface TextInputProps { ... };

export interface TextInputExtendedProps extends Omit<
JSX.IntrinsicElements['input'],
'onSelect' | 'size' | 'placeholder'
>, TextInputProps {};

declare const TextInput: React.FC<TextInputExtendedProps>;

export { TextInput };

Roadmap

Thanks to @Isaius for check and get this list for us.

These do not extend JSX.IntrinscElements in their props interface but in the declare block.

• Accordion
• AccordionPanel
• Anchor
• Carroussel [ComponentClass]
• CheckBox
• CheckBoxGroup
• Clock
• Collapsible
• DataTable
• Diagram
• Distribution
• DropButton
• FileInput
• FormField
• Grid
• Grommet
• Heading
• Image
• Layer
• List
• Markdown
• MaskedInput
• Paragraph
• RadioButton
• RadioButtonGroup
• RangeInput
• RangeSelector
• SideBar
• Stack
• Tab
• Table
• TableBody
• TableCell
• TableFooter
• TableHeader
• TableRow
• Tabs
• Text
• TextArea
• Video
• WorldMap

These are OK, but do not follow the pattern, using Type instead interface:

• Box
• Button
• Calendar
• Drop

Only ComponentClass, but not wrong:

• Chart

Rules for Migration

• Pick a maximum of 4 components at the same time
• Comment which one you will work
• Work is done! Create the PR with a maximum of 4 components per PR
• Wait for the review and the merge. After merged, you can pick new ones.

[ericsoderberghp]

I believe that we need to revisit the approach taken in #4909 . If there are existing callers who have extended the current ComponentProps to add some instrinsic properties, I think their code will break due to the new properties already existing. I’m thinking we should preserve the existing behavior and add a new export for the extension:

export interface TextInputProps { ... };

export interface TextInputExtendedProps extends Omit<
JSX.IntrinsicElements['input'],
'onSelect' | 'size' | 'placeholder'
>, TextInputProps {};

declare const TextInput: React.FC<TextInputExtendedProps>;

export { TextInput };

[abnersajr]

Thank you @Isaius for the contribution. The list was added to the issue. Just to not bloat the discussion, could you delete it please?