How to reduce redundancy when declaring custom object types? #724
-
I have been using Nexus to declare my schema so far but have seen that Pothos is a library that might supersede it in the long run. Unfortunately I am struggling to understand how to map a use-case from Nexus to Pothos. As far as I understand Pothos wants to operate on Typescript types or classes as much as possible to expose or compute fields that way. However I find myself in a situation where I have "virtual entities/types" that don't originate from a database as a whole. For example I have the following code with Nexus which has no underlying Typescript type and is just declared for the GraphQL API: export const Player = objectType({
name: 'Player',
definition(t) {
t.nonNull.id('id');
t.string('name');
t.string('email');
}
});
export const me = queryField('me', {
type: Player,
resolve: async (source, args, context, info) => {
const session = await context.getSession();
if (session === null) return null;
const { id, name, email } = session.user;
return { id, name, email };
}
}); However Pothos seems to require many redundant declarations for the same player type as seen here: const Player = builder
.objectRef<{
readonly id: string;
readonly name?: string | null;
readonly email?: string | null;
}>('Player')
.implement({
fields: (t) => ({
id: t.exposeString('id', {}),
name: t.exposeString('name', { nullable: true }),
email: t.exposeString('email', { nullable: true })
})
});
builder.queryFields((t) => ({
me: t.field({
type: Player,
nullable: true,
resolve: async (root, args, ctx) => {
const session = await ctx.getSession();
if (session === null) return null;
const { id, name, email } = session.user;
return { id, name, email };
}
})
})); Is there something I am missing? Is this redundancy with the generic for |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
The short answer is to use the simple objects plugin: https://pothos-graphql.dev/docs/plugins/simple-objects The longer answer is that by default Pothos does not assume your data and your API have the same shape, which means that in Pothos you define the shape of your data (using a typescript type, class, or some other (plugin specific) method), then you define fields and define how those fields are resolved from that data. It may feel a little repetitive at first, especially in a new project, but this pattern pays off as you evolve apps over time and things start to grow more complex. The simple objects plugin gives you a way to quickly define objects without specifying types of resolvers. These types then just expect you to pass data that matches the shape of the API which makes them easy to use for the simple use cases |
Beta Was this translation helpful? Give feedback.
The short answer is to use the simple objects plugin: https://pothos-graphql.dev/docs/plugins/simple-objects
The longer answer is that by default Pothos does not assume your data and your API have the same shape, which means that in Pothos you define the shape of your data (using a typescript type, class, or some other (plugin specific) method), then you define fields and define how those fields are resolved from that data. It may feel a little repetitive at first, especially in a new project, but this pattern pays off as you evolve apps over time and things start to grow more complex.
The simple objects plugin gives you a way to quickly define objects without specifying types of resolver…