Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with namespaced keywords #15

Closed
borkdude opened this issue Mar 27, 2017 · 3 comments
Closed

Dealing with namespaced keywords #15

borkdude opened this issue Mar 27, 2017 · 3 comments

Comments

@borkdude
Copy link

borkdude commented Mar 27, 2017

I'm trying to retrofit an existing REST endpoint (which returned EDN) to GraphQL using Lacinia.
The response contains a lot of namespaced keywords. Has Lacinia support for querying these?

@hlship
Copy link
Member

hlship commented Mar 27, 2017

Namespaces are a problem because the slash character is not allowed in a name (http://facebook.github.io/graphql/#sec-Names).

@bcarrell
Copy link
Contributor

bcarrell commented Mar 27, 2017

This is doable, but like @hlship mentioned, you'll need to find a way to map these keys in your data structure to keys in your GraphQL schema. My suggestion would be to override the default-field-resolver (see the default one here) to instead look up using whatever namespacing you're using.

Does that help?

EDIT: To elaborate, you could name your schema field name something like namespace__foo and then make your default-field-resolver fn passed to compile do something like if the field name has double underscores, look up in v using the namespaced keyword. Basically, you'll have to create a convention here since names can't have slashes.

@borkdude
Copy link
Author

@bcarrell That's exactly what I've been doing as a workaround, the double underscores. Looks like it's more difficult to retrofit GraphQL on our backend, as we are using URIs as keys as well. I'll close this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants