React-apollo: How to pass non-scalar (object) query parameters?

[lumberg72]

I have a case where the server schema requires a parameter as an object with multiple properties.

1. When passing dynamic parameters to the query, do we always HAVE to define the query parameters and types? I am talking about the first line within GET_DOG_PHOTO (see below). Since that's already done on the server side (and it will tell us if we get it wrong), I would rather not bother with doing it again on the client side.
   If there's a way around that, then we can skip the next question #2.

2. I'm guessing the answer to #1 is "yes, you have to". In that case, not all of my parameters are simple String & Int types. Sometimes I have objects with nested properties (see example below of what I attempted). And again, they have already been detailed out in the server schema. I have no problem passing them in via an Axios post. But I'm trying to learn Apollo and I think I'm missing something big.
   Obviously I could break out the properties as individual/flat parameters, then rebuild the object in the query call.. but that would be super ugly.

Thoughts?
Thanks

[email protected]
[email protected]

Based on the example found here... https://www.apollographql.com/docs/react/essentials/queries.html

const GET_DOG_PHOTO = gql`
  query Dog($breed: String!, $otherCriteria: Object) {
    dog(breed: $breed, otherCriteria: $otherCriteria) {
      id
      displayImage
    }
  }
`;

const DogPhoto = ({ breed }) => (
  <Query query={GET_DOG_PHOTO} variables={{ breed, otherCriteria: {size: 10, weight: 20} }}>
    {({ loading, error, data }) => {
      if (loading) return null;
      if (error) return `Error!: ${error}`;

      return (
        <img src={data.dog.displayImage} style={{ height: 100, width: 100 }} />
      );
    }}
  </Query>
);

[lumberg72]

Never mind. I somewhat figured it out.
The object type name (i.e. "OtherCriteria") just needs to match what's mapped on the server. I didn't occur to me to try that at first. Since that type does not exist on the client, I just assumed it would fail.

So I think I've just about got everything working. Although, I'm still not sure why I have to re-map the query signature on the client side. It seems like I'm just ending up with a lot of redundancy. But maybe it'll make more sense as I get deeper into it.

[evenfrost]

Yeah, this duplication of client/server side type definitions is a mystery to me as well.

[mathiasfc]

Never mind. I somewhat figured it out.
The object type name (i.e. "OtherCriteria") just needs to match what's mapped on the server. I didn't occur to me to try that at first. Since that type does not exist on the client, I just assumed it would fail.

So I think I've just about got everything working. Although, I'm still not sure why I have to re-map the query signature on the client side. It seems like I'm just ending up with a lot of redundancy. But maybe it'll make more sense as I get deeper into it.

Thanks =)

[manichandra]

@lumberg72 how did you remap the query signature ? I tried creating an interface on the client side adding it as a type but it didn't work for me