Helper types for the component props about relay-compiler-language-typescript HOT 15 OPEN

Cc: @alloy

from relay-compiler-language-typescript.

This sounds like a great idea!

I was thinking about something similar, but different, recently; which is to provide typed aliases of commitMutation in the generated artefacts such that you don’t need to do anything else then import { commitMyModuleMutation } from "__generated__/MyModuleMutation.graphql".

from relay-compiler-language-typescript.

The initial thoughts I had for this I've actually since found out is not ideal (from working with our own codebase using some slightly different techniques but with regards to this issue, same stuff applies).

I would however still like to approach the feeling of just being able to add more fragments and have it working without any further code modifications - I'm just not exactly sure how that would work.

How would you want your idea to work? Like could you show some short examples of what would be generated and how you would call it?

from relay-compiler-language-typescript.

Currently we generate types for the input variables and response, but casting commitMutation is left up to the user –currently I’m not even sure that commitMutation accepts the proper type arguments, but that aside–. I’m thinking that besides generating these types, we also emit something like:

import { commitMutation, CommitMutation } from "relay-runtime"
export const commitArtistSearchResultsArtistMutation: CommitMutation<ArtistSearchResultsArtistMutationVariables, ArtistSearchResultsArtistMutationResponse> = commitMutation

The user can then do:

import { commitArtistSearchResultsArtistMutation as commitMutation } from "__generated__/ArtistSearchResultsArtistMutation.graphql"

Or without the import alias in case a module has multiple mutations.

from relay-compiler-language-typescript.

Yeah right now commitRelayModernMutation doesn’t take any type parameters for either variables or response, so that needs to be fixed anyways.

from relay-compiler-language-typescript.

Ah I see what you mean. In general I think getting variables and output type needed for a query and mutation (and subscriptions for that matter) texts would be very nice.

Something like:

MyQuery.ts

interface MyQueryVariablesAndResult {
  " $variables": VariablesType;
  " $result": ResultType;
}
const node: ConcreteRequest & MyQueryVariablesAndResult = (function(){ ... ])();

Then we could type the commitMutation (and stuff around the QueryRenderer) to work with the $variables and $result properties if they exist (using the awesome stuff from TS 2.8 that we made use for for component prop types).

from relay-compiler-language-typescript.

I’m not sure I see how that would work, can you provide an example of the commitMutation function? The thing is that, unlike the create*Container functions, we never pass any type to commitMutation from which we could infer any typings, we just pass data.

from relay-compiler-language-typescript.

Something like this:

Typescript Playground

from relay-compiler-language-typescript.

Hmm, but the mutation parameter is supposed to be the GraphQL document, so it can’t exist in the artefact file.

from relay-compiler-language-typescript.

I think I might have messed up some details in the link, here's an updated version that might show what I'm after.

In short, the actual GraphQL document we export out of the artifact file I want to decorate it with extra typing information regarding it's variables and it's result type (ie. the payload of the mutation/subscription/query). This way we can add generic type parameters and infer the variables and result based off the operation itself (without providing extra generic type parameters) as shown in the example.

from relay-compiler-language-typescript.

Are you thinking of the MyOperation query being replaced by e.g. the babel plugin for the processed operation? Because that doesn’t help at dev time when it’s just supposed to be a tagged template string.

from relay-compiler-language-typescript.

I think I know what you're getting at now. I've completely forgotten how this is supposed to work exactly, my bad.

With that in mind, you're right we cannot make infer the variable and payload types without a generic type argument. Perhaps that is alright though? I mean there's not much difference to calling:

commitMutation<AddProfileMutation>(...);

As opposed to:

commitAddProfileMutation(...);

If this is not desirable enough then we either need to look into doing something like you described - or see if there's some TypeScript specific extensions we can utilize to get the types flowing based off the template literals.

from relay-compiler-language-typescript.

To build on the idea of creating a TypeScript plugin it should be possible to add a Language Server Plugin that would add linting quick fixes to add the generic type argument (and import it from the proper file). How does this sound to you?

from relay-compiler-language-typescript.

Ooooh, that sounds amazing 👌

But yeah, I agree, just adding the type argument should suffic. I guess I was reasoning based off how we currently emit 2 types for variables and response and specifying those both each time feels a little tedious.... but we obviously control how that gets emitted and so should just fix it there 😄

from relay-compiler-language-typescript.

The commitMutation (and QueryRenderer) part is done.

As to your OP, I think we need to expand the plugin interface and have relay-compiler specify the type of container so we can appropriately type the relay parameter. Also, I’m thinking that we can just add to the existing artefact files and without the need for a factory type. E.g. for a refetch container we could emit something like:

interface MyRefetch_foo_props {
  relay: RelayRefetchProp
  foo: MyRefetch_foo
}

Which is then used in the user’s code extend their props interface from.

(I’m not a big fan of the interface naming with _props, but coming up short with ways to improve that)

from relay-compiler-language-typescript.