Add TypeScript components generation support.

[T4rk1n]

Add typescript component support for Dash components, custom replacement for react-docgen.

Use with dash-generate-components CLI.

Requires npm modules installed as devDependencies:

• typescript

Contributor Checklist

• I have run the tests locally and they passed. (refer to testing section in contributing)
• I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR

optionals

• I have added entry in the CHANGELOG.md
• If this PR needs a follow-up in dash docs, community thread, I have mentioned the relevant URLS as follows
  • this GitHub #PR number updates the dash docs
  • here is the show and tell thread in Plotly Dash community

[T4rk1n]

@alexcjohnson Ready for review, thank you.

[T4rk1n]

Component template: https://github.com/T4rk1n/dash-typescript-component-template

It install Dash from this PR, there's an issue with the setup and the installation is not complete but it generates the component.

[snehilvj]

I want to refactor the dash-mantine-components library with typescript support. Is there any estimate as to when this will be merged into dev?

[T4rk1n]

@snehilvj

The current solution requires that all components in a package are in TypeScript, we would like to more easily migrate existing libraries by combining the extract-meta script with the new ts compiler for .tsx files only. I am working on that and then I think it's good.

[snehilvj]

@T4rk1n I had one more request. Will this change support imported prop types? So for example many a times react components accept common props such as style, class_name, padding props (p, px, py, pr, pt, etc.), margin props (m, mx, my, etc). It would be nice if these props can be defined in one module and imported in all the components.

[T4rk1n]

@snehilvj
The generator will work with imported types from local files and libraries, you don't have to define the props in the component file. I would recommend against using local .d.ts files for the prop types as editors will include them without exports but the compiler will not pick them if the file is not imported in the component files.

You can use all the typescript type utilities to combine & manipulate the prop types. Like if you want to wrap the props of an html element but remove the onEvent props and other props that are not json compatible, you can do something like this for an audio component wrapper:

./src/props.ts

import React from 'react'

export type DashComponentProps = {
    /**
     * Unique ID to identify this component in Dash callbacks.
     */
    id?: string;
    /**
     * Update props to trigger callbacks.
     */
    setProps: (props: Record<string, any>) => void;
}

type InvalidHtmlProps =
    | 'dangerouslySetInnerHTML'
    | 'defaultChecked'
    | 'defaultValue'
    | 'suppressContentEditableWarning'
    | 'suppressHydrationWarning'
    | 'ref'
    | 'key'
    | 'async';

type EventsProps = keyof Omit<React.DOMAttributes<any>, 'children'>;
type AriaProps = keyof React.AriaAttributes;
export type HtmlOmittedProps = InvalidHtmlProps | EventsProps | AriaProps;

type SourceProps = Omit<React.SourceHTMLAttributes<any>, HtmlOmittedProps>;

export type AudioProps = Omit<React.AudioHTMLAttributes<any>, HtmlOmittedProps> & Partial<{
    sources: JSX.Element[] | SourceProps[];
    /**
     * Set to true to play the audio source.
     */
    play: boolean;
    status: 'playing' | 'paused' | 'stopped';
    /**
     * READONLY: true when the audio can be played.
     */
    can_play: boolean;
    /**
     * READONLY: true when the audio has been download completely.
     */
    can_play_through: boolean;
}> & DashComponentProps;

Then import it in the component:

./src/components/Audio.tsx

import React from 'react'
import { AudioProps } from '../props';


const Audio = (props: AudioProps) => {
    // Remove the custom props & keep the rest to give to the html component.
    const { sources, play, status, can_play, can_play_throught, setProps, ...audioProps } = props;
    return (
        <audio {...audioProps}>
            // ...
        </audio>
    )
}

export default Audio;

[snehilvj]

You made me cry. 😭 Thanks for all the efforts @T4rk1n.

[rohitranjan017]

@T4rk1n , I tried using https://github.com/T4rk1n/dash-typescript-component-template but, it is not generating the python class file in the example_component directory. How can I run the python-dash app with the typescript component?

[rohitranjan017]

I realized that the metadata.json file is empty and hence the python class is not being generate? @T4rk1n , could you please comment on this?

[T4rk1n]

@rohitranjan017 There were a few errors in the template because it was not up to date with the latest development here. I updated the template and this branch, should work now if you generate again from the template.

[alexcjohnson]

@T4rk1n this is looking great! My only real questions about it are about how folks will learn to use it:

• Are you still thinking of merging your template into the main dash-component-boilerplate as an option?
• What if someone using the JS build pipeline wants to add a TS component to their package? What instructions can we give them? Is it sufficient to say something like "add this tsconfig file, add these deps to your package.json, and modify your webpack config like this"?

[T4rk1n]

Are you still thinking of merging your template into the main dash-component-boilerplate as an option?

I think for now I'd like to keep them separated, the original boilerplate has more stuff in it and the component it generates is a class component while the new template is structured differently and generates a functional component.

[alexcjohnson]

💃 Excellent work!

I think for now I'd like to keep them separated, the original boilerplate has more stuff in it and the component it generates is a class component while the new template is structured differently and generates a functional component.

We don't need to deal with this before merging this PR, but if the original has unnecessary things in it or is out-of-date we should update it. I think it would be a mistake to split component creation into two different cookiecutters, because it would give people a false impression that JS/TS is a difficult transition, also it'd be more for us to maintain and more for users to learn about.