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 want to combine typescript schema types and typescript mapper types together to generate a combined type that combines fields of both types. This would reduce the amount of typescript conflicts in resolver code.
For example in the following code snippets 1st one is the default graphql codegen generated typescript type for User. The 2nd one is the database type generated for User. In resolver code resorting to using only one of the types results in much headache, instead we should just combine both the types and use a type that's much more flexible.
typeUser=GraphQLSchemaUser|DataBaseUser;// 3rd combined graphql schema + database typetypeUser={id: string|numberbestFriend?: User|nullbestFriendId: string}// when we choose to resolve bestFriend within a Query type resolverconstQuery={user: (_parent,args)=>{constuser=awaitdb.users.findOne({where: {id: args.id});constbestFriend=awaitdb.users.findOne({where: {id: user.bestFriendId});return{...user, bestFriend}}}// when we choose to resolve bestFriend in a User field resolverconstQuery={user: (_parent,args)=>{constuser=awaitdb.users.findOne({where: {id: args.id});returnuser;}}// User type fields resolverconstUser={bestFriend: (parent,args)=>{constbestFriend=awaitdb.users.findOne({where: {id: parent.bestFriendId});returnbestFriend}}
Now when resolvers make use of the 3rd type we have the freedom to resolve bestFriend within the query/mutation resolvers or delegate it to the User field resolver bestFriend which can then make use of the parent.bestFriendId to resolve the corresponding bestFriend. Best of both worlds and we retain all the type information.
For two fields sharing the same name, which field's type should be used?
I think using type of the field which is less restrictive makes sense. For example take a look at the email field of the User type, in 1st case email field is nullish(both nullable and undefined), this could be required for cases where we don't want to reveal email field information to a client freely. In 2nd case it is not nullish because it represents the database state of the field.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I want to combine typescript schema types and typescript mapper types together to generate a combined type that combines fields of both types. This would reduce the amount of typescript conflicts in resolver code.
For example in the following code snippets
1st
one is the default graphql codegen generated typescript type for User. The2nd
one is the database type generated for User. In resolver code resorting to using only one of the types results in much headache, instead we should just combine both the types and use a type that's much more flexible.Now when resolvers make use of the
3rd
type we have the freedom to resolvebestFriend
within the query/mutation resolvers or delegate it to theUser
field resolverbestFriend
which can then make use of theparent.bestFriendId
to resolve the correspondingbestFriend
. Best of both worlds and we retain all the type information.For two fields sharing the same name, which field's type should be used?
I think using type of the field which is less restrictive makes sense. For example take a look at the
email
field of theUser
type, in 1st caseemail
field isnullish(both nullable and undefined)
, this could be required for cases where we don't want to revealemail
field information to a client freely. In 2nd case it is notnullish
because it represents the database state of the field.Now when we combine the
1st
and2nd
cases we should opt for type of the email field ofUser
in1st
case which is less strict:-email?: string | null
Beta Was this translation helpful? Give feedback.
All reactions