You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have my first lacinia app in production and am enjoying it so far so thanks for the hard work up front.
Currently to resolve union and interface types correctly, we have to tag-with-type or use records. I find these a bit troublesome especially if the type to be tagged is nested somewhere in the data I am returning.
I like to keep my graphql resolvers as a very thin layer on top of business logic which may or may not be shared by other non-graphql access methods. In the above case of nested data structures, I either have to tag it where the child value is created, polluting the namespace with lacinia specific code, or in the resolver, do some cumbersome unwrapping, tagging, and wrapping.
I’ve written several graphql services in javascript before and one thing I liked there was being able to define a resolveType function (https://graphql.org/graphql-js/type/#graphqluniontype). This is literally a function that takes the value and returns some type identifier, eg based on some attribute of a map. This could perhaps be implemented as additional placeholder attributes in the schema.edn and nicely prevents graphql requirements to leak into other code.
What do you think?
The text was updated successfully, but these errors were encountered:
Any news about this feature? I'd like to have in lacinia something like I have in javascript
LdapObject: {__resolveType(obj,context,info){if(obj&&obj.objectClass.includes("computer")){return"LdapComputer";}if(obj&&obj.objectClass.includes("group")){return"LdapGroup";}if(obj&&obj.objectClass.includes("user")){return"LdapUser";}returnnull;// GraphQLError is thrown},},
I have my first lacinia app in production and am enjoying it so far so thanks for the hard work up front.
Currently to resolve union and interface types correctly, we have to tag-with-type or use records. I find these a bit troublesome especially if the type to be tagged is nested somewhere in the data I am returning.
I like to keep my graphql resolvers as a very thin layer on top of business logic which may or may not be shared by other non-graphql access methods. In the above case of nested data structures, I either have to tag it where the child value is created, polluting the namespace with lacinia specific code, or in the resolver, do some cumbersome unwrapping, tagging, and wrapping.
I’ve written several graphql services in javascript before and one thing I liked there was being able to define a resolveType function (https://graphql.org/graphql-js/type/#graphqluniontype). This is literally a function that takes the value and returns some type identifier, eg based on some attribute of a map. This could perhaps be implemented as additional placeholder attributes in the schema.edn and nicely prevents graphql requirements to leak into other code.
What do you think?
The text was updated successfully, but these errors were encountered: