What about typescript support?

[blasterpistol]

No description provided.

[jamesplease]

I don't use TypeScript, but I'm open to PRs adding whatever it takes to get TS support here. It may make sense for it to live over in DefinitelyTyped, though? Not too sure.

@DenisNeustroev , feel free to open a PR here or on DefinitelyTyped if there's an easy to add this. It'd be great if someone wanted to help maintain that anytime a new library version is released, too.

Thanks ✌️

[dyst5422]

After looking at this for the last half hour, it's non-trivial to type in its current formulation. To actually preserve types, a very long lived TypeScript proposal would have to be implemented (originally submitted back in 2015) so I wouldn't hold my breath. For reference, this is the proposal that would support this.

[jamesplease]

Thanks for investigating this @dyst5422 ! I admit that that proposal is over my head (I can't even read currently-supported TypeScript 😅), but I trust your evaluation.

If there are any changes we could make to the API to support this, then I think that is possibly worth considering. TS types are pretty useful for some text editors, such as VSCode, so I think that even users who aren't using TS would benefit ✌️

I'll close this issue out for now, but if any future visitor has any ideas, just post a comment here and I'd be happy to reopen!

[alsiola]

Copied from #59

Further to #40 it is possible to provide TypeScript support for the library (albeit in a slightly imperfect way), despite the somewhat tricky API to type, and current TS limitations.

A basic start to types is shown below - as you can see there needs to be a specific type for each number of components that is passed in the array, which is not ideal (and is the case solved by variadic types in TS as mentioned in the previous issue), but it can be made to work. It is the same approach taken by other libraries such as Ramda.

With respect to where to publish them, it is generally preferred to publish with the package itself where possible. This allows any API change to be immediately reflected in the types, and prevents installing the wrong version of types for the wrong version of library. Very little effort is needed to publish them - generally and index.d.ts file inside the package, with a ``types: "index.d.ts"` entry in the package.json.

If there is still appetite for supporting this then I'm happy to expand on the below and make a PR.

/// <reference types="react" />

declare module "react-composer" {
    interface ReactComposerProps1<T> {
        components: [
            ReturnType<
                React.FunctionComponent<{
                    children?: (injected: T) => React.ReactElement<any>;
                }>
            >
        ];
        children: (injected: [T]) => React.ReactElement<any>;
    }

    interface ReactComposerProps2<T, U> {
        components: [
            ReturnType<
                React.FunctionComponent<{
                    children?: (injected: T) => React.ReactElement<any>;
                }>
            >,
            ReturnType<
                React.FunctionComponent<{
                    children?: (injected: U) => React.ReactElement<any>;
                }>
            >
        ];
        children: (injected: [T, U]) => React.ReactElement<any>;
    }

    interface ReactComposerProps3<T, U, V> {
        components: [
            ReturnType<
                React.FunctionComponent<{
                    children?: (injected: T) => React.ReactElement<any>;
                }>
            >,
            ReturnType<
                React.FunctionComponent<{
                    children?: (injected: U) => React.ReactElement<any>;
                }>
            >,
            ReturnType<
                React.FunctionComponent<{
                    children?: (injected: V) => React.ReactElement<any>;
                }>
            >
        ];
        children: (injected: [T, U, V]) => React.ReactElement<any>;
    }

    class ReactComposer<T> extends React.Component<ReactComposerProps1<T>> {}
    class ReactComposer<T, U> extends React.Component<
        ReactComposerProps2<T, U>
    > {}
    class ReactComposer<T, U, V> extends React.Component<
        ReactComposerProps3<T, U, V>
    > {}

    export default ReactComposer;
}

[jamesplease]

Thanks for the suggestion, @alsiola ! I'm not skilled enough at TS to be able to interpret that, but I'd be willing to pull it down and give it a try.

Also, go ahead and open a PR. If we get a few 👍's from folks who pull it down and try it with some success, then I'd definitely merge that in.

[alsiola]

Thanks for getting back to this @jamesplease. I've been playing with this and have a working version locally, so I'll tidy that up and get a PR opened in the next day or two.

[jamesplease]

Very cool! I appreciate you contributing some of your time into improving this project, @alsiola , and I think other developers will appreciate it, too 😄