Need examples for DRYer code patterns

[miloofcroton]

I have made my code much DRYer (do-not-repeat-yourself-er) from the initial example, but I'm a bit stuck in trying to extract correct types from the meta values that Pothos uses.

Here is what I have so far (these are across several files for organization purposes):

in util/pothos:

import { QueryFieldBuilder } from '@pothos/core';
import SchemaBuilder from '@pothos/core';

export type PothosT = QueryFieldBuilder<
  PothosSchemaTypes.ExtendDefaultTypes<{}>,
  {}
>

export const builder = new SchemaBuilder({});

in resources/root/schema:

import { getPost, getPosts } from '../posts/queries';
import { builder } from '../../util/pothos';

builder.queryType({
  fields: (t) => ({
    post: getPost(t),
    posts: getPosts(t),
  }),
});

export const schema = builder.toSchema({});

in resources/posts/objects:

import { builder } from '../../util/pothos';
import { User } from '../users/objects';
import { Users } from '../users/mocks';
import { Comments } from '../comments/mocks';
import { Comment } from '../comments/objects';

export interface IPost {
  id: string;
  authorId: string;
  title: string;
  content: string;
}

export const Post = builder.objectRef<IPost>('Post');

Post.implement({
  fields: (t) => ({
    id: t.exposeID('id'),
    title: t.exposeString('title'),
    content: t.exposeString('content'),
    author: t.field({
      type: User,
      nullable: true,
      resolve: (post) => [...Users.values()].find((user) => user.id === post.authorId),
    }),
    comments: t.field({
      type: [Comment],
      resolve: (post) => [...Comments.values()]
        .filter((comment) => comment.postId === post.id),
    }),
  }),
});

in resources/posts/mocks:

import faker from '@faker-js/faker';
import { FAKER_SEED } from '../../util/constants';
import { IPost } from './objects';

faker.seed(FAKER_SEED)

export const Posts = new Map<string, IPost>();

for (let i = 1; i <= 100; i += 1) {
  Posts.set(String(i), {
    id: String(i),
    authorId: String(faker.datatype.number({ min: 1, max: 100 })),
    title: faker.lorem.text(),
    content: faker.lorem.paragraphs(2),
  });
}

in resources/posts/queries:

import { DEFAULT_PAGE_SIZE } from '../../util/constants';
import { Post } from './objects';
import { Posts } from './mocks';
import { PothosT } from '../../util/pothos';


export const getPost = (t: PothosT) => t.field({
  type: Post,
  nullable: true,
  args: {
    id: t.arg.id({ required: true }),
  },
  resolve: (root, args) => Posts
    .get(String(args.id)),
})

export const getPosts = (t: PothosT) => t.field({
  type: [Post],
  nullable: true,
  args: {
    take: t.arg.int(),
    skip: t.arg.int(),
  },
  resolve: (root, { skip, take }) => [...Posts.values()]
    .slice(
      skip ?? 0,
      (skip ?? 0) + (take ?? DEFAULT_PAGE_SIZE)
    ),
})

in resources/posts/requests:

import { params, query, types, alias } from 'typed-graphqlify'
import { IPost } from './objects'

export const GET_POSTS_VARS = { take: 5 }

export const GET_POSTS_FIELDS: Partial<IPost>[] = [{
  id: types.string,
  title: types.string,
}]

// typed-graphqlify input object
export const GET_POSTS = {
  posts: params(GET_POSTS_VARS, GET_POSTS_FIELDS),
}

// a typescript type for return value
export const GET_POSTS_TYPE = typeof GET_POSTS;

// a graphql query object
export const GET_POSTS_QUERY = query(GET_POSTS)

My remaining issues are:

• I cannot use much of Pothos on the front end, as far as I'm aware. I'm currently using the TypeScript types and another library (typed-graphqlify) to bridge the gap. This is unrelated to this issue, but I thought I would mention it. I wish this library was a full stack solution, particularly given that there's no schema being generated and thus few libraries can integrate well with it.
• I want to make GET_POSTS_VARS get the correct type from the getPosts args type and the GET_POSTS_FIELDS to get the correct type from the getPosts resolver return value, but I've not been successful yet.

Currently working on something like:

export type GetPostsValue = ReturnType<typeof getPosts>

But that only gives me a FieldRef type (from the Pothos lib). I tried exporting ArgBuilder from Pothos to get the arg types correctly, but that's not working either. I had limited time to look at this today, but I'm hoping to have a good discussion on this soon. Maybe to get something added to the docs or an explanation of the limitaitons.

[hayes]

Hey,

Not sure if I fully understand everything you are asking for here, so I created an interactive version of your example here: https://stackblitz.com/edit/typescript-nlswbq?file=resources/posts/objects.ts

Stack blitz doesn't load tsconfig correctly, so you will need to turn strict mode off and back on again before types are correct in the tsconfig when using the link above.

I added some logic to extract types from args defined in pothos:

You can define args separately like this:

export const getPostArgs = builder.args((t) => ({
  id: t.id({ required: true }),
}));

export const getPost = (t: PothosT) =>
  t.field({
    type: Post,
    nullable: true,
    args: getPostArgs,
    resolve: (root, args) => Posts.get(String(args.id)),
  });

export const getPostsArgs = builder.args((t) => ({
  take: t.int({ required: false }),
  skip: t.int({ required: false }),
}));

export const getPosts = (t: PothosT) =>
  t.field({
    type: [Post],
    nullable: true,
    args: getPostsArgs,
    resolve: (root, { skip, take }) =>
      [...Posts.values()].slice(
        skip ?? 0,
        (skip ?? 0) + (take ?? DEFAULT_PAGE_SIZE)
      ),
  });

Then you can extract types for the args like this

import { InputShapeFromFields } from '@pothos/core';
export const GET_POSTS_VARS: InputShapeFromFields<typeof getPostsArgs> = {
  take: 5,
};

Regarding export type GetPostsValue = ReturnType<typeof getPosts>. You can get the return value of a resolver with something like:

export type GetPostsValue = ReturnType<typeof getPosts> extends FieldRef<
  infer T,
  any
>
  ? T
  : never;

This will get you the expected return type for the resolver of the given field. FieldRefs do not track the arguments that the field accepts, and do not know what fields are available on the type they return. The type that a resolver returns is NOT THE SAME as the types that can be queried for on the client. There is no way in pothos to get a type that represents all the fields available on a type. This limitation exists for a number of reasons, but one of the biggest is that building schemas should be modular, and additional fields for types can be added later either by plugins, or using some of the builder methods like t.objectField. Similarly the types for arguments are not preserved by field refs, currently the type information for arguments only exists in the context of the field options defined for the field (like the resolver) and you can't extract them from a field definition. The reasoning here is more historic that intentional, but the workaround is to define args separately if you want to access their types (as shown above).

Regarding client types and integration with other tools. Pothos is Code first, but that doesn't mean you can't have a schema file. Every app I've build with pothos generates a schema file that can be used to help with client side type safety.

See https://pothos-graphql.dev/docs/guide/printing-schemas and https://pothos-graphql.dev/docs/guide/generating-client-types for examples on how this might be set up. Those docs could probably have some more options and details, but should get you started. Happy to provide more detailed guidance if you have a specific client side tool you are trying to work with.

[miloofcroton]

This helped clean up some of my code, so thank you.

However, it doesn't solve every problem. I need to continue working on reducing the boilerplate.

Before digging too far into that, I want to address this first:

The type that a resolver returns is NOT THE SAME as the types that can be queried for on the client. There is no way in pothos to get a type that represents all the fields available on a type.

This limitation exists for a number of reasons, but one of the biggest is that building schemas should be modular, and additional fields for types can be added later either by plugins or using some of the builder methods like t.objectField.

Can you expand on this? What fields would be added later by plugins, and how would builder methods like t.objectField prevent the above code from extracting the correct type?

[miloofcroton]

This is where I'm currently at, still waiting to hear why I can't extract the return type from the resolver definition.

I'm finding that I can make the code more brief, but I can't make it type safe back to front in this manner anyway, rending this effort moot. There's no type safety (adhering to the schema) when I put in those values to createRequest for instance.

// posts/objects

// (type of database Post, no ORM implementation yet)
export interface IPost {
  id: string;
  authorId: string;
  title: string;
  content: string;
}

export const Post = builder.objectRef<IPost>('Post');

Post.implement({
  fields: (t) => ({
    // database fields
    id: t.exposeID('id'),
    title: t.exposeString('title'),
    content: t.exposeString('content'),

    // graphql-only fields
    author: t.field({
      type: User,
      nullable: true,
      resolve: (post) => [...Users.values()]
        .find((user) => user.id === post.authorId),
    }),
    comments: t.field({
      type: [Comment],
      resolve: (post) => [...Comments.values()]
        .filter((comment) => comment.postId === post.id),
    }),
  }),
});

// posts/queries.ts

export const getPostsArgs = builder.args((t) => ({
  take: t.int({ required: false }),
  skip: t.int({ required: false }),
}));

export const getPosts = (t: PothosT) => t.field({
  type: [Post],
  nullable: true,
  args: getPostsArgs,
  resolve: (root, { skip, take }) => [...Posts.values()]
    .slice(
      skip ?? 0,
      (skip ?? 0) + (take ?? DEFAULT_PAGE_SIZE)
    ),
})

// posts/requests.ts

export const usePostsQuery = createRequest<typeof getPosts, typeof getPostsArgs>(
  { take: 5 },
  [{
    id: types.string,
    title: types.string,
  }],
  'posts' as const,
  true,
)

// in a React component file

const [{ data, error, fetching }] = usePostsQuery()

// some util file (these are referenced above)

export const useUrqlQuery = <T, V>(
  gqlquery,
  variables
) => (): UseQueryResponse<T, V> => {
  const urqlQuery = useQuery<T, V>({
    query: query(gqlquery).toString(),
    variables: variables,
  });

  return urqlQuery;
}

type Operation = "Query" | "Mutation" | "Subscription" | "Object" | "Interface"

type PothosOperationType<O extends Operation = "Query"> = (t: PothosT) => FieldRef<any, O>

type PothosArgsType = {
  [key: string]: InputFieldRef<string | number, "Arg">;
}

type PothosResolverReturn<QueryType extends PothosOperationType> = Partial<
  ReturnType<QueryType>[typeof outputFieldShapeKey][number]
>[]

type PothosResolverReturnArray<QueryType extends PothosOperationType> = Partial<
  ReturnType<QueryType>[typeof outputFieldShapeKey][number]
>[]

type OperationArgs<ArgType extends PothosArgsType> = Partial<InputShapeFromFields<ArgType>>


const createRequest = <OperationType extends PothosOperationType, ArgType extends PothosArgsType>(
  args,
  fields,
  key: string,
  isArray,
) => {

  if (isArray) {
    const QUERY = {
      [key]: params(args as OperationArgs<ArgType>, fields as PothosResolverReturnArray<OperationType>),
    }

    const useThisQuery = useUrqlQuery<typeof QUERY, OperationArgs<ArgType>>(
      QUERY,
      args as OperationArgs<ArgType>
    )

    return useThisQuery
  }

  else {
    const QUERY = {
      [key]: params(args as OperationArgs<ArgType>, fields as PothosResolverReturn<OperationType>),
    }

    const useThisQuery = useUrqlQuery<typeof QUERY, OperationArgs<ArgType>>(
      QUERY,
      args as OperationArgs<ArgType>
    )

    return useThisQuery
  }
}

[hayes]

A simple example would be something like:

Post.implement({
  fields: (t) => ({
    id: t.exposeID('id'),
    title: t.exposeString('title'),
    content: t.exposeString('content'),
  }),
});

builder.objectField(Post, 'author', t => t.field({
  type: User,
  nullable: true,
  resolve: (post) => [...Users.values()]
    .find((user) => user.id === post.authorId),
}))

Here you can see an example of the Post implementation does not have any information about the author field. A resolver for a Post might return something like { id, title, content, authorId }. Trying to infer types for the client from a resolver like that would not tell you anything about the author field, and you would also not know that authorId is not a field that is exposed by the API. Looking at the implementation of Post, we could extract some information on what a Post has, which is slightly more accurate to what the API will expose, but again, we don't know anything about author.

These are some very simple examples, when you start looking at things like aliases, connections in the relay plugin, response unions created by the errors plugin, etc, it becomes very clear that you can't use any specific piece of the Pothos API to infer types for client side queries in a robust way. The general approach you need to take is use something like graphql-code-generator or the relay compiler to generate client types based on the schema pothos outputs.

If you want to infer client side types from your API definitions, I would highly recommend checking out TRPC as a potential alternative, because it is specifically designed for that use case.