Description
TypeScript Version: 3.8.2 (reproduced on next
as of publishing time, which was 3.9.0-dev.20200227)
Search Terms: "array destructuring", "array object destructuring"
Code
I am trying to utilize TypeScript bindings for the following function provided by documentation for graphql-ruby, for a TypeScript React project utilizing Apollo as a GraphQL client and Rails as the server:
import { ApolloLink } from "apollo-link"
...
const hasSubscriptionOperation = ({ query: { definitions } }) => {
return definitions.some(
({ kind, operation }) => kind === 'OperationDefinition' && operation === 'subscription'
)
}
const link = ApolloLink.split(
hasSubscriptionOperation,
new ActionCableLink({cable}),
httpLink
);
According to the type bindings for ApolloLink.split
, I should be able to add the type binding of Operation
to the single parameter of hasSubscriptionOperation
, like so:
const hasSubscriptionOperation = ({ query: { definitions } }: Operation) => {
return definitions.some(
({ kind, operation }) => kind === 'OperationDefinition' && operation === 'subscription'
)
}
Expected behavior:
There should be no tsc errors. The object destructuring on the definitions.some()
parameter is valid because kind
and operation
are both valid attributes.
Actual behavior:
Nope! I am getting a compile error on the operation
destructured parameter. BUT, what's weird is that if I rely on direct attribute access instead of destructuring, then I get no compile time issues, like so:
const hasSubscriptionOperation = ({ query: { definitions } }: Operation) => {
return definitions.some(
(definition) => definition.kind === 'OperationDefinition' && definition.operation === 'subscription'
)
}
Bug in destructuring???
Playground Link:
I could not get this to work in TypeScript Playground. So, hopefully CodeSandbox will suffice. See index.ts
. https://codesandbox.io/s/friendly-thunder-nsicx
Related Issues:
I noticed this open bug, but it appeared to be describing a separate issue on first glance: #32465
Also this bug, but it appears to be closed as fixed: #33282