graphql 2019-06-20 | Slack Archive

orestis07:06:54

I’ve just upgraded to lacinia 0.3.3 and my schema is no longer valid. First of all, GREAT error messages 🙂 Here’s the offending thing:

:labels
       {:type ...,
        :description ...,
        :resolve #'nosco.graphql.resolvers.users/user-userlabels},

should satisfy

  fn?

or

  (fn
   [%]
   (satisfies?
    com.walmartlabs.lacinia.resolve/FieldResolver
    %))

orestis07:06:05

Shouldn’t that be ifn? instead?

gklijs08:06:29

There where some automatic conversions that no longer happen with the latest version. I used a number for id, and had to make it a string from the frontend. Not sure if that helps. But it's probably something similar with the schema, like a key to string needing an explicit (name x) or something.

orestis08:06:48

You are referring to Scalars, right? My case is a plain resolver…

orestis09:06:27

Filed here: https://github.com/walmartlabs/lacinia/issues/291

👍 4

xiongtx22:06:20

Basic ❓ r.e. GraphQL / Lacinia: I often find myself wanting to do the following:

{:objects {:foo {:fields {:foo_1 {:type String
                                  :resolve :resolve-foo-1}}
                 :resolve :resolve-foo}}}

And directly querying like { foo { foo_1 } }. But this is invalid, and I always need:

{:objects {:foo {:fields {:foo_1 {:type String
                                  :resolve :resolve-foo-1}}}}
 :queries {:foo {:type :foo
                 :resolve :resolve-foo}}}

Is it always necessary to do it this way, or am I missing an easier option?

domkm23:06:51

Could you give an example of what kind of objects you're creating and querying? Mostly, top level queries are things like "search for user" or "get list of projects".

domkm23:06:44

Your code reminds me slightly of the Node pattern (used in Relay) where most objects implement interface Node { id: ID! } and you have a top level query field that looks like node(id: ID!): Node for selecting specific nodes

2019-06-20

Channels