Lacinia - use the data inside ::lacinia/selection in my resolvers

. Is this considered a stable public api/data?
It is not. Use it are your peril. However, there's the selections API that exposes the most useful information in there.

What I’m trying to see is the field “type” for non-leaf resolvers. I can infer if from the keyword namespaces in the data from the selections api but that seems a bit indirect. Is there a better way?
12 replies
steveb8n 7 days ago
since I always have an “id” field in my queries, here’s what seems to work using the selection api
steveb8n 7 days ago

(some->> (executor/selections-tree context)
(select-first [MAP-KEYS #(= "id" (name %))])
namespace
keyword)

steveb8n 7 days ago
that’s specter in the second step so not material to this question
steveb8n 7 days ago
just wondering if there’s a more direct way to do this but I’m happy to move forward with this solution
hlship:clj: 6 days ago
The conflict here is that we really don't want to lock down the structure of the many internal keys in the context, as that handcuffs against any future changes and improvements.
hlship:clj: 6 days ago
But at the same time, there's often a need for data we don't expose.
hlship:clj: 6 days ago
So we've been gradually extending the preview API, which is something we can test and maintain, even in the face of a reorganization of the data in the context.
hlship:clj: 6 days ago
At this point, we can add more data to the maps returned by https://walmartlabs.github.io/apidocs/lacinia/com.walmartlabs.lacinia.executor.html#var-selections-seq2 without breaking any clients, so that's who I'd prefer to go.
hlship:clj: 6 days ago
Returning more field type data, as well as field and argument directives, would address a lot of needs, AFAIK.
steveb8n 6 days ago
yes, that would pretty much be what I need. that said, I can use config/factories for now to achieve the same result. since I generate my schemas, this is not a big deal.

Start with the executor/selections-tree usage and the selections-seq2 API documentation linked in the discussion; compare the available selection data with the config/factories workaround. Define how field type data should be exposed without depending on internal context keys, then confirm the selections API returns the required type information.