Add default values for useFragment generic types

[jerelmiller]

This PR adds default types for the useFragment generic definitions. This improves the experience when passing generic types directly to the useFragment function.

Currently, you can get proper types on data when using TypedDocumentNode. Take the following example:

const ItemFragment: TypedDocumentNode<Item> = gql`
  fragment ItemFragment on Item {
    text
  }
`

const { data } = useFragment({ fragment: ItemFragment })

type Data = typeof data; 
// type Data = Item | undefined

If using the generic gql helper, you get unknown as expected:

const ItemFragment = gql`
  fragment ItemFragment on Item {
    text
  }
`

const { data } = useFragment({ fragment: ItemFragment })

type Data = typeof data; 
// type Data = unknown

If, however, I want to provide my own types to useFragment, the current implementation forces you to provide the TArgs type.

const ItemFragment = gql`
  fragment ItemFragment on Item {
    text
  }
`

const { data } = useFragment<Item>({ fragment: ItemFragment }) // [Error] Expected 2 type arguments, but got 1.

This is rather annoying because I have to import OperationVariables just to use TData.

This PR ensures a default value is properly set so that I can just pass the TData generic and get proper types.

const ItemFragment = gql`
  fragment ItemFragment on Item {
    text
  }
`

const { data } = useFragment<Item>({ fragment: ItemFragment }) 
type Data = typeof data
// type Data = Item | undefined

Checklist:

• If this PR contains changes to the library itself (not necessary for e.g. docs updates), please include a changeset (see CONTRIBUTING.md)
• If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
• Make sure all of the significant new logic is covered by tests

[changeset-bot]

🦋 Changeset detected

Latest commit: 26f0ec1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@apollo/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jerelmiller]

Previously this would be set to unknown by default. Should we keep the same here? I changed this to any to be a bit more in line with our current useQuery/other hooks.

[alessbell]

Personally, I usually prefer unknown to any but +1 to keeping with existing hooks here.

[jerelmiller]

Ya same. I think its fine for now to be in line with the rest of Apollo.

As an aside, I'd love to consider using unknown as the default everywhere for v4. Perhaps this change can be made there.

[alessbell]

LGTM!