:interceptors defaults to the result of calling graphql-interceptors

That's a map of interceptor name to interceptor map. You can replace keys in the map, or add new keys/interceptors to the map.

There's additional functions in com.walmartlabs.lacinia.pedestal.interceptors to allow you to set dependencies, to control the order of execution of the interceptors.

@hlship How do union type in Lacinia work? I’m trying to get one working but keep getting the error, “Field resolver returned an instance not tagged with a schema type.” My resolver looks like so,

(def resolve-client
  ^ResolverResult
  (fn [context args _value]
    (resolve-as
      (if-let [client (db/client args)]
        client
        {:message "Client does not exist"}))))

Never mind, I got it to work! I’m not sure if this is the most efficient way or the correct way, but for those who are interested…

(def resolve-client
  ^ResolverResult
  (fn [context args _value]
    (resolve-as
      (if-let [client (db/client args)]
        (tag-with-type client :Client)
        (tag-with-type {:message "Client does not exist"} :Error)))))

So i believe with resolve-as its as simple as providing a second argument and that turns it into an error

(def resolve-client
  ^ResolverResult
  (fn [context args _value]
    (resolve-as
      (if-let [client (db/client args)]
        client
        "Client does not exit" {:message "Client does not exist"}))))

So that would return a resolver result with an error inside of it

I’ve not used tag-with-type before, that looks interesting

Can I use composite types for field arguments?

Can you give an example of what you mean

:get-token           {:type    :Token
                        :args    {:authdata    {:type :AuthData}
                                  ;; :password {:type :String}
                                  }
                        :resolve :authn/get-token}

yes i believe you can

:objects
......
  :AuthData
  {:fields {:login    {:type :String}
            :password {:type :String}}}

but i think you need to make it an input-object?

http://lacinia.readthedocs.io/en/latest/input-objects.html?highlight=input

oh, thanks a lot

Exactly what I watching for

well it might not be mandatory

but i think its useful

because you can have something like

:AuthDataInput

and mirror the updateable fields in the object

if that makes sense?

yep, I'm agreed with separate entity for input objects.

If you use a graphiql plugin it might break it

i think some of the graphiql plugins get quite picky about every thing have descriptions and things

Works as expected

:thumbsup:

I would code it as:

(if-let [client (db/client args)]
      client
      (resolve-as nil {:message "Client does not exist."}))

Interesting

What does providing a nil do instead?

It ensures that Lacinia doesn't try to select any nested fields. Further, this use makes it clear that "just client" is the normal flow, and resolve-as is the failure path.

Thats great

So then potentially you will only get :errors with that message map inside of it?

Returning a string will result in Lacinia attempting to select fields inside the String; I believe that would be either an internal exception or a flurry of errors added to the response.

Yeah i get errors more to do with the object fields being missing

so for example if a user had a non null id, and i throw an error when it should be a user

it would say error non null field is null

would i still get that with nil?

You may be your explicit error and (I believe) an additional error if the field type is non-null.

ah ok

But you shouldn't use the non-null qualifier on the type, if there's a possibility that it is not available as in this case.

So how do you handle mutations that go wrong?

(if that makes sense)

Same way. When things go wrong, (resolve-as nil error). The big question is what goes in the error map.

So say i had a mutation on an object which had non-null fields. Should the fields be not non-null, if theres a chance that if the mutation breaks it will return nil

(reads a bit like a tongue twister sorry)

No, you would be ok. The logic is: - invoke the field resolver - If it returns nil and the type has non-null then add an error - if it returns non-nil, perform sub-selections So the fact that sub-selection fields are non-null is irrelevant, Lacinia doesn't go down that path.

oki dokie thanks!