Fork me on GitHub
#graphql
<
2020-06-08
>
mafcocinco04:06:51

Is there any way, perhaps via a function against the context, to know the field name that the current resolver is resolving? The selections-tree, critically, provides the list of selections below the current resolver. It seems it would be useful, in some contexts, to know the name of the field that is currently being resolved. Additionally, is there any way to know if the current field is being resolved as a single value or as a list? I find myself often writing two versions of what are ostensibly the same resolver: foo and foos, with the only different being that one returns a single instance of a foo object and the other a sequence of the same type.

hiredman04:06:13

(if you have foos foo is redundant)

mafcocinco04:06:08

so if a field is resolved to a single instance of foo (rather than a list of foos), if the resolver for that field returns a list (maybe with only one instance of foo in the list), Lacinia will coerce the list into the single instance?

hiredman04:06:04

I just have a strong preference for collection oriented apis over single item apis, and if the same resolve works for both just use lists

mafcocinco04:06:30

I see. I just disagree. There are definitely instances where a list of foo objects doesn’t make any sense. It might be more convenient from an implementation perspective but the point of having a schema is to communicate how a data model works to a user and telling them they get a list of things when, in reality, there is only ever going to be one thing in the list seems wrong to me. But, reasonable people could disagree.

mafcocinco04:06:54

Plus, semantically, it is wrong. There are cases where one thing in a schema maps, uniquely, to something else. Seems like the schema should reflect that relationship.

mafcocinco04:06:38

First part of my of my question still stands. Is there any way for a resolver to know what field it is currently resolving?

hlship15:06:47

Not with the current APIs. If you're willing to deal with future disruption, you can check the code (or just print out the context) and see the keys that Lacinia uses to keep track of everything.

mafcocinco15:06:11

Do you think either/both of these features (i.e. “Am I resolving a single instance or a list?” and “What field am I currently resolving?“) are features that are worth supporting? I.e. has anyone else asked for them besides me? 🙂

mafcocinco15:06:50

The ability to know if we are resolving a list vs a single object is definitely one that would allow us to reduce duplication in our resolver code.

hlship16:06:02

An API that identified the current field AND field and argument directives would be useful to many!

d5p23:06:36

yeh we extract those via (get-in (:com.walmartlabs.lacinia/selection context) [:field-definition :type]) in our resolvers , and keep an eye out for changes in newer releases , an api would be great tho