Use metadata for tagging, whenever possible - use wrapper type only when metadata not supported about lacinia

[hlship]

Tagging should be done last. I'm thinking that we should perform a mixed operation, only resorting to the new tagged wrapper if the object does not support metadata. Using metadata, which works in nearly all situations, it doesn't matter when you tag.

[gusbicalho]

Hm, my use case is: I have generic adapters which I want to run on all resolvers (camel-casing keys, changing enum to uppercase strings, etc). They can't know what tag to use unless the resolver somehow returns that along with the result.
If they can't transform a TaggedValue, I'll have to use an intermediate representation which has a tag I can use directly, and transform that to a lacinia/TaggedValue on the last step of the decorator. But that looks like just remaking TaggedValue.

[hlship]

I agree; the current solution in 0.17.0 caters too much to the edge case. I have similar code to yours, where I put metadata on the map early, and then tag it last. That's too complicated.

[lilactown]

Is there even a way to do nested resolvers without metadata + later tagging? See here: https://github.com/Lokeh/graphql-demo/blob/master/src/graphql_demo/resolvers.clj

In order to even get it to resolve:

{
  human(id: "1000") {
    friends {
      name
    }
}

Involved adding a :type field and then processing them later to tag them. Seems really clunky.

[hlship]

The type of friends is character. Lacinia needs a way to determine whether each friend in the list is a human or a droid, as the resolver for each (even for a common field such as name) could be different.

Remember: interfaces don't define resolvers, only objects do.

Without inheritance, there needs to be another way.

One approach may be #66 .