React-apollo: Apollo doesn't support Date() in input variable

[patrickml]

So when double clicking/re-clicking a link that loads a gql query I am expirencing something really odd where the second load is missing the result from they query under this.props.data

Here is a gif of this in action

https://cl.ly/0O3p0y0D1122

And the error is undefined so there isn't an error and i'm not seeing the data re-requested in the network tab

Steps to Reproduce

import { graphql } from 'react-apollo';
import gql from 'graphql-tag';
import EventList from 'components/Bots/Events';

const query = gql`
  query BotEventPagination($botId: ID!, $cursor: Date!, $page: Int!, $per: Int!, $config: TableConfig, $filter: JSON) {
    bot(botId: $botId) {
      id
      name
      properties {
        key
        type
        event
      }
      events(cursor: $cursor, page: $page, per: $per, config: $config, filter:$filter) {
        cursor
        count
        totalPages
        documents {
          id
          platform
          platformId
          silverId
          organizationId
          event
          createdAt
          values
          botId
          user {
            firstName
            lastName
            email
          }
        }
      }
    }
  }
`;

export default graphql(query, {
  options: ({ params: { botId } }) => ({
    variables: {
      botId,
      cursor: new Date(),
      page: 1,
      per: 10,
      config: {
        sort: {
          key: 'createdAt',
          dir: -1,
        },
      },
      filter: {},
    },
  }),
})(EventList);

Expected Behavior

Existing cached data reused and available

Version

• [email protected]
• [email protected]

[patrickml]

So the issue is passing in the new Date() as a param. The client seems to have an issue when you pass date types through.

[cvle]

We ran into a similar/same issue.

We got an empty query result after a certain mutation using either updateQueries or update with no errors. It used to work before we changed the fragment definition.

This fragment in our query caused the empty query result after applying our mutation:

const commentViewFragment = gql`
  fragment commentView on Comment {
    id
    body
    created_at
    status
    tags {
      name
    }
    user {
        id
        name: username
    }
    action_summaries {
      __typename
      count
      current_user {
        id
        created_at
      }
    }
  }
`;

Meanwhile putting the action_summaries definition in a separate fragment works without issues:

const actionSummaryViewFragment = gql`
  fragment actionSummaryView on ActionSummary {
    __typename
    count
    current_user {
      id
      created_at
    }
  }
`;

const commentViewFragment = gql`
  fragment commentView on Comment {
    id
    body
    created_at
    status
    tags {
      name
    }
    user {
        id
        name: username
    }
    action_summaries {
      ...actionSummaryView
    }
  }

Also removing created_at from action_summaries resolves our issue.
This works for us now, because we are not using it atm.

https://github.com/coralproject/talk/pull/526/commits/15d410ba12932e21a28ebd92d1bef4dd1a2b2e9d

[patrickml]

@cvle our fix was to do new Date().toISOString() when passing the variable

[cvle]

@patrickml Thanks! Will try it out when we run into this again.

[helfer]

@patrickml did you only start seeing this issue after the last update? What's the most recent version where this bug does not occur?

[patrickml]

@helfer I wish I could be more useful here, but we had just implemented our own version of pagination so we didn't have this issue until then. I was able to widdle it down to passing in Date as a Date and not a string

[helfer]

My guess is that the issue here is that Apollo Client can't magically know how to serialize things, which means it's up to the developer to make sure the variable is properly serialized before passing it to Apollo. I'm inclined to close this issue, but I do think we need a much better error message when things like that happen, so I'd love to have a simple reproduction that I can play around with to figure out where to intercept inputs like this. Could someone provide a really simple reproduction of this with react-apollo-error-template? That would help a great deal!

[patrickml]

Well that's just the thing the query works the first time it's when the
cache is being accessed that it became a problem. But I will try to get
together an example sometime this week
On Tue, Apr 25, 2017 at 7:07 PM Jonas Helfer [e-mail]
wrote:

My guess is that the issue here is that Apollo Client can't magically know
how to serialize things, which means it's up to the developer to make sure
the variable is properly serialized before passing it to Apollo. I'm
inclined to close this issue, but I do think we need a much better error
message when things like that happen, so I'd love to have a simple
reproduction that I can play around with to figure out where to intercept
inputs like this. Could someone provide a really simple reproduction of
this with react-apollo-error-template
https://github.com/apollographql/react-apollo-error-template? That
would help a great deal!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apollographql/react-apollo/issues/654#issuecomment-297190854,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHOuuf8Cwvr2z9FR6mZ66568pzhmRkDSks5rznykgaJpZM4NG_dY
.

[helfer]

Hm, that's interesting, but it makes perfect sense. Can you look at what the Date gets serialized to in the request? I assume it's something like "Tue Apr 25 2017 16:18:57 GMT-0700 (PDT)". If it gets put in the store under that, the second query wouldn't be able to read it, unless it also serializes the date before checking (which I thought it did).

I now agree that this is most likely a bug that needs fixing, and a reproduction would really help a great deal to figure out what's really going on inside the client. Thanks @patrickml !

[thebigredgeek]

@helfer The de-facto way of handling stuff like this is by calling toJSON on complex types like Date objects. Almost every single complex type has a toJSON method, which is automatically invoked whenever you try to convert something to JSON. In the case of Date, toJSON returns an ISO date. A simple fix for this would be to call JSON.parse(JSON.stringify(variables)) within HTTPNetworkInterface before passing the variables to whatwg-fetch

[helfer]

@thebigredgeek I'm a bit dubious whether this will fix the issue here (after all the problem is with loading from cache, not the network interface), but if you think it will work, go for it! Once we have a reproduction, you can try it out.

[thebigredgeek]

Ah, I didn't read this properly haha. Wondering if it's still fixable using the same technique though?

[patrickml]

@helfer, since I'm not able to create that example yet, here is a photo of the cache.

Now this photo was taken from the Apollo Chrome Extention so I'm not sure if they do something fancy here

[cvle]

The issue I encountered also only involves the cache and our custom Scalar type Date. I'm trying to reproduce with a simplified example.

[cvle]

Not entirely sure if it is related. My issue turned out to be a bit different: https://github.com/apollographql/react-apollo/issues/658.

[stale[bot]]

This issue has been automatically labled because it has not had recent activity. If you have not received a response from anyone, please mention the repository maintainer (most likely @jbaxleyiii). It will be closed if no further activity occurs. Thank you for your contributions to React Apollo!

[schmeter]

still broken

[the-simian]

This issue has come back in the latest version you have to do .toISOString() on your Date objects or it will only send a {}

I opened an issue here: https://github.com/apollographql/apollo-client/issues/4335