Latest Apollo Client sends Date objects as {} and now requires .toISOString()

Intended outcome: Apollo recognizes Date() objects and prepares them thusly for GraphQL consumption, as was done in previous versions

Actual outcome: The sending new Date() as an argument for an input (such as a filter) yet get interpreted as empty objects {} instead of the Date Type Graphql recognizes

How to reproduce the issue: You can repro the issue by creating a GraphQL query and using something like a date range filter and passing new Date() as args for inputs. The GraphQL error will throw, stating that an expected type of Date was not received.

The fix (currently) use new new Date.toISOString() instead of ajust new Date() object. So you need to call that on any dates you want to send with apollo-client

Versions I’m using the latest npm-published apollo client and these plugins at these versions:

    "apollo-cache-inmemory": "1.4.0", 
    "apollo-client": "2.4.9", 
    "apollo-link": "1.2.6", 
    "apollo-link-context": "1.0.12", 
    "apollo-link-error": "1.1.5", 
    "apollo-link-http": "1.5.9", 
    "apollo-link-redux": "0.2.1", 
    "apollo-link-retry": "2.2.8", 
    "apollo-link-ws": "1.0.12",
    "react-apollo": "2.3.3",

[danilobuerger]

Even if it was unintended behavior beforehand, that’s still a breaking change in behavior.

So is every bug fix if you want to see it like that.

Did you read the report?

Yes I did.

But again - if your library ‘did a thing’ and it stops ‘doing that thing’ and its not a major semver change, that’s a bug report.

Thats incorrect. If it did that thing, and that thing was considered a bug, and then that thing (a bug) was fixed, it would be a patch change, not major.

Here’s the semver spec if you’re confused about how it works

Thanks, how kind of you…

So if you dropped serialization of Dates into iso formats (you did)

Please provide prove of your claim by providing a minimal reproducible sample.

[danilobuerger]

Let me start over, I think it will become clearer what I meant by supported.

Date is a custom scalar and not part of the graphql spec. So on your graphql server you would declare it as a custom scalar:

scalar Date

And then implement functions to marshal and unmarshal it. That doesn’t mean though that you are unmarshaling the date as defined per RFC 3339 (or ISO 8601). It could be

parseValue(value) {
  if (value === 'today') {
    return new Date();
  }
  return new Date(1970,1,1)
}

so totally different than you would expect. Because reasons 😅.

Now on the client, we have no way of knowing how the server actually marshals and unmarshals a custom scalar, and thus a date. Therefor, its unsupported.

That doesn’t mean however, that new Date() wouldn’t serialise as expected. It will. Internally JSON.stringify is used and anything you input it will be serialised according to its rules.

To recap:

• Serialising new Date() to work with the servers scalar Date is not supported.
• Serialising new Date() will result in whatever JSON.stringify does:

> JSON.stringify({ date: new Date() })
{"date":"2019-01-23T21:46:27.285Z"}

You can try this out:

import { InMemoryCache } from "apollo-cache-inmemory";
import { ApolloClient } from "apollo-client";
import { HttpLink } from "apollo-link-http";
import gql from "graphql-tag"

const client = new ApolloClient({
  cache: new InMemoryCache(),
  link: new HttpLink({
    fetch: (url, options) => {
      console.log(options.body);
      return fetch(url, options);
    }
  })
})
const TEST_MUTATION = gql`
mutation foo($date: String!) {
  bar(date: $date) {
    id
  }
}
`
client.mutate({ mutation: TEST_MUTATION, variables: { date: new Date() }})

this will log:

{"operationName":"foo","variables":{"date":"2019-01-23T21:51:29.291Z"},"query":"mutation foo($date: String!) {\n  bar(date: $date) {\n    id\n    __typename\n  }\n}\n"}

containing the correctly serialised date.