graphql

steveb8n 2020-06-16T01:04:29.184200Z

Q: I want to use the data inside ::lacinia/selection in my resolvers. Is this considered a stable public api/data?

hlship 2020-06-16T16:13:27.184700Z

It is not. Use it are your peril. However, there's the selections API that exposes the most useful information in there.

steveb8n 2020-06-16T23:19:15.186200Z

I’m glad I asked 🙂. 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?

hlship 2020-06-17T16:16:44.187100Z

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 2020-06-17T16:16:53.187300Z

But at the same time, there's often a need for data we don't expose.

hlship 2020-06-17T16:17:22.187500Z

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 2020-06-17T16:19:50.187700Z

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 2020-06-17T16:20:35.187900Z

Returning more field type data, as well as field and argument directives, would address a lot of needs, AFAIK.

steveb8n 2020-06-18T00:13:20.188100Z

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.

steveb8n 2020-06-18T00:13:41.188300Z

touch base if you decide to add more data. I can chime in with that would help me

steveb8n 2020-06-18T00:13:48.188500Z

thanks for the feedback