React-apollo: TypeScript - props function of graphql HOC fail type checking

[lirbank]

The example in the docs does not work, and I have not found a way around it either:

https://www.apollographql.com/docs/react/recipes/static-typing.html#props

Reproduction:

https://stackblitz.com/edit/react-ts-rpb3ex

TS Error:

Argument of type '{ options: ({ episode }: InputProps) => { variables: { episode: string; }; }; props: ({ data }: O...' is not assignable to parameter of type 'OperationOption<InputProps, Response, Variables, ChildDataProps<InputProps, Response, Variables>>'.
  Types of property 'props' are incompatible.
    Type '({ data }: OptionProps<InputProps, Response, OperationVariables>) => { error?: ApolloError; netwo...' is not assignable to type '(props: OptionProps<InputProps, Response, OperationVariables>, lastProps?: void | ChildDataProps<...'.
      Type '{ error?: ApolloError; networkStatus: number; loading: boolean; variables: OperationVariables; fe...' is not assignable to type 'ChildDataProps<InputProps, Response, Variables>'.
        Object literal may only specify known properties, and 'error' does not exist in type 'ChildDataProps<InputProps, Response, Variables>'.

Version

• [email protected]
• [email protected]

[skovy]

@lirbank hopefully this PR will resolve this issue: https://github.com/apollographql/react-apollo/pull/2094

A bit of a sledgehammer 🔨 approach you could take in the short term would be to use any:

graphql<InputProps, Response, Variables, ChildProps>(HERO_QUERY, {
  options: ({ episode }) => ({
    variables: { episode }
  }),
  props: ({ data }) => ({ ...data } as any)
});

Based off that example, it looks like a slightly more correct type cast might look something like this:

type Props = ChildDataProps<InputProps, Response, Variables>;

graphql<InputProps, Response, Variables, Props>(HERO_QUERY, {
  options: ({ episode }) => ({
    variables: { episode }
  }),
  props: ({ data, ownProps }) => ({ data, ...ownProps} as Props)
});

[skovy]

@lirbank FYI the above PR was merged recently. Hopefully, it resolves the issue for you! Is this issue good to close?

[jameslaneconkling]

I just forked @lirbank 's example and bumped react-apollo to 2.1.9 and it's still an issue.

https://stackblitz.com/edit/react-ts-f276th?file=index.tsx

[skovy]

@jameslaneconkling I don't think a release has been cut with the type updates yet. It looks like version 2.1.9 was cut on July 4, this fixed was merged 3 days ago (July 14).

[jameslaneconkling]

👍 good to know. What's the best way to track releases?

[adams-brian]

I just bumped into this as well and confirmed that #2094 fixes the issue for me.

Looking forward to this being released, thanks @skovy!

[jameslaneconkling]

@brian-lives-outdoors how are you testing against the latest snapshot? It looks like the build artifacts aren't checked in to github, and I haven't seen instructions for local builds. Thanks for the help!

[adams-brian]

@jameslaneconkling I'm not running a local build, I just tracked down the typing issue and fixed it in my local package, and then saw that @skovy's pull request made the same changes on master.

There's no actual code changes with the fix, just type definitions, so doing the type assertion on the object you return from the props function works fine until the new release.

If you want to preview the fix you can change the props type of OperationOption in your local react-apollo/types.d.ts from this:

props?: (props: OptionProps<TProps, TData>, lastProps?: TChildProps | void) => TChildProps;

to this:

props?: (props: OptionProps<TProps, TData, TGraphQLVariables>, lastProps?: TChildProps | void) => TChildProps;

If I'm not mistaken, that is the only change from this fix that will show up in the release.

[lirbank]

@skovy thanks for fixing this! I am moving from HOCs to the render props pattern so I don't really have the issue anumore, but I tried to upgrade react-apollo on the Stackblitz example - which, as @jameslaneconkling already has pointed out does, not work yet since the new release has not been published yet. It should be easy to confirm the fix once the new version has been published.

Thanks a lot for fixing the issue!

[amwill04]

Dont know if I am missing something but the example found
https://www.apollographql.com/docs/react/recipes/static-typing.html#props still fails type checking with the following:

TS2345: Argument of type '{ options: ({ episode }: InputProps) => { variables: { episode: string; }; }; props: ({ data }: OptionProps<InputProps, Response, Variables>) => {}; }' is not assignable to parameter of type 'OperationOption<InputProps, Response, Variables, ChildDataProps<InputProps, Response, Variables>>'.
[app]   Types of property 'props' are incompatible.
[app]     Type '({ data }: OptionProps<InputProps, Response, Variables>) => {}' is not assignable to type '(props: OptionProps<InputProps, Response, Variables>, lastProps?: void | ChildDataProps<InputProps, Response, Variables> | undefined) => ChildDataProps<InputProps, Response, Variables>'.
[app]       Type '{}' is not assignable to type 'ChildDataProps<InputProps, Response, Variables>'.
[app]         Type '{}' is not assignable to type 'InputProps'.
[app]           Property 'episode' is missing in type '{}'.

checked the types.d.ts file to make sure that it was updated with @brian-lives-outdoors fix.

The only way I "fixed" it was using ChildProps as opposed to ChildDataProps

const withCharacter = graphql<InputProps, Response, Variables, ChildProps<InputProps, Response>>(HERO_QUERY, {
    options: ({ episode }) => ({
        variables: { episode },
    }),
    props: ({ data, ownProps }) => ({ ...data, episode: ownProps.episode }),
});

[reverie]

@lirbank What's an example of the render props pattern? I'm trying to move away from the graphql HOC.

[lirbank]

@reverie check out these links for the general concept of render props:

https://reactjs.org/docs/render-props.html
https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce

Apollo specific:
https://www.apollographql.com/docs/react/essentials/queries.html#basic
https://www.apollographql.com/docs/react/essentials/mutations.html#basic

[rosskevin]

Closing - housekeeping

[amwill04]

I dont really understand why this is closed.

Either the typings are incorrect or the documentation is.

It seems to be this line:

// The partial wrapping DataProps & MutateProps
export interface OptionProps<TProps = any, TData = any, TGraphQLVariables = OperationVariables> extends Partial<DataProps<TData, TGraphQLVariables>>, Partial<MutateProps<TData, TGraphQLVariables>> {
    ownProps: TProps;
}

Why would this need to be Partial and if it does what is the best practice for checking in the props option in the hoc?

[joshycube]

This should be re opened and documentetion to be corrected.

[MrToph]

Not sure why @joshycube 's comment is marked as disruptive.

The example from the apollo-typescript documentation has type errors and there's no clear way how to resolve them anywhere.

It would be nice if we could open this issue again

[hwillson]

@MrToph it was marked as disruptive because his original non-edited comment was:

The documentation is utterly rubbish.

We're always looking for ways to improve the docs, but getting new features in and keeping the docs up to date is definitely a balancing act, and requires a significant amount of developer effort. We're open to working on suggestions to improve the docs, or better yet merging community PR's in that do that, but saying the docs are utterly rubbish is condescending to the countless developers who have taken time out of their day to help make the docs better.

Please consider opening a new issue with specific details around the areas of the docs that are causing you grief, and we'll take a look. Thanks!

[amwill04]

@hwillson

If that was the original comment then yeah - that is disruptive and frankly insulting.

I would question why there needs to be another issue opened. As my comment above states a clear example of either the docs been wrong/unclear or the types being incorrect. My question was looking for guidance as to which it is. If I got direction then I’m more than happy to contribute.

[hwillson]

Fair enough @amwill04 - re-opening.

On a related note, we're working on new docs structure changes that will be launching when React Apollo 3 is published. We're going to include more TS examples across the board, alongside vanilla JS examples (we'll have a code sample language switcher in place). All code samples will be reviewed/updated and verified to be accurate.

[hwillson]

React Apollo has been refactored to use React Hooks behind the scenes for everything, which means a lot has changed since this issue was opened (and a lot of outstanding issues have been resolved). We'll close this issue off, but please let us know if you're still encountering this problem using React Apollo >= 3.1.0. Thanks!