also allow Complete and Partial datastate type overrides

[phryneas]

I first thought that we would be okay with only a Streaming override, but in the end we don't know what certain codegen setups might create, so we probably also need a Complete and Partial override.

That would also be an escape hatch for use cases like #12738, allowing users to introduce DeepReadonly themselves.

Since Partial is already a TS builtin and PartialData felt weird, I opted for a namespace that exports all three - the name TData is very much up for debate here.

[changeset-bot]

🦋 Changeset detected

Latest commit: 2531d7c

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

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

[pkg-pr-new]

npm i https://pkg.pr.new/apollographql/apollo-client/@apollo/client@12740

commit: 2531d7c

[github-actions]

size-limit report 📦

Path	Size
import { ApolloClient, InMemoryCache, HttpLink } from "@apollo/client" (CJS)	42.62 KB (0%)
import { ApolloClient, InMemoryCache, HttpLink } from "@apollo/client" (production) (CJS)	37.73 KB (0%)
import { ApolloClient, InMemoryCache, HttpLink } from "@apollo/client"	32.55 KB (0%)
import { ApolloClient, InMemoryCache, HttpLink } from "@apollo/client" (production)	26.97 KB (0%)
import { ApolloProvider } from "@apollo/client/react"	5.7 KB (0%)
import { ApolloProvider } from "@apollo/client/react" (production)	960 B (0%)
import { useQuery } from "@apollo/client/react"	7.48 KB (0%)
import { useQuery } from "@apollo/client/react" (production)	2.72 KB (0%)
import { useLazyQuery } from "@apollo/client/react"	6.95 KB (0%)
import { useLazyQuery } from "@apollo/client/react" (production)	2.19 KB (0%)
import { useMutation } from "@apollo/client/react"	6.52 KB (0%)
import { useMutation } from "@apollo/client/react" (production)	1.75 KB (0%)
import { useSubscription } from "@apollo/client/react"	6.63 KB (0%)
import { useSubscription } from "@apollo/client/react" (production)	1.86 KB (0%)
import { useSuspenseQuery } from "@apollo/client/react"	8.49 KB (0%)
import { useSuspenseQuery } from "@apollo/client/react" (production)	3.73 KB (0%)
import { useBackgroundQuery } from "@apollo/client/react"	8.22 KB (0%)
import { useBackgroundQuery } from "@apollo/client/react" (production)	3.5 KB (0%)
import { useLoadableQuery } from "@apollo/client/react"	8.54 KB (0%)
import { useLoadableQuery } from "@apollo/client/react" (production)	3.81 KB (0%)
import { useReadQuery } from "@apollo/client/react"	6.45 KB (0%)
import { useReadQuery } from "@apollo/client/react" (production)	1.68 KB (0%)
import { useFragment } from "@apollo/client/react"	6.49 KB (0%)
import { useFragment } from "@apollo/client/react" (production)	1.74 KB (0%)

[jerelmiller]

Honestly I'm not opposed to DataState.Complete<TData> if we can make it both a type and a namespace. Otherwise I'd consider going with something like DataValue as the namespace. I think TData might be too confusing.

data: DataValue.Complete<TData>;

[jerelmiller]

Eh the more I think of it, I kind of like DataValue a bit more since it is meant to describe the "value" of the data property. Thoughts on that name?

[phryneas]

Yeah, sounds good to me.

[jerelmiller]

Love it!

[phryneas]

Ugh, merged instead of squashing... manually undid that and squash-merged locally into 1c6e03c