Proper typings for local API

[chris-schra]

Dear All,

Payload looks really promising but I wonder if there's a reason why clients are not really typed (or did I miss something)?

Maybe a code sample demos the "issue" better.

Currently I can do something like this

payload
      .find<PayloadTypes.User>({
        collection: PayloadCollections.Users.slug,
        where: {
          "invalidField": {
            equals: 1,
          },
          "numberField": {
            equals: "invalidString",
          },
        },
      })

Before I continue working on that, I just want to double-check if there's nothing I missed.

Here's just a simple POC:

type Operator =
  | "equals"
  | "not_equals"
  | "in"
  | "not_in"
  | "exists"
  | "greater_than"
  | "greater_than_equal"
  | "less_than"
  | "less_than_equal"
  | "like"
  | "near";

type WhereField<T> = {
  [key in Operator]?: T;
};

type Where<T extends Record<string, unknown>> = Merge<
  {
    or?: Where<T>[];
    and?: Where<T>[];
  },
  {
    [key in keyof T]?: WhereField<T[key]>;
  }
>;

export const PayloadCollections = {
  Users,
};

export const findTyped = async <
  T extends TypeWithID,
  C extends ValueOf<typeof PayloadCollections> = ValueOf<
    typeof PayloadCollections
  >
>(
  request: Request,
  collection: C,
  filter: Where<T>
): Promise<PaginatedDocs<T> | undefined> => {
  const payloadClient = (request as any).payload as typeof PayloadType;
  return payloadClient.find<T>({
    collection: collection.slug,
    where: filter,
  });
};

Now I get nice auto-completion on Collections and filters - no more invalid fields.

[jmikrut]

Hey @chris-schra — good call. We have some of what you've got above, but this is nice to see. We do see a lot of value in how to further type incoming where queries and your solution is nice.

If you want to make a PR for this, we'd be happy to see, but otherwise we can address this and improve types of where queries soon.

Thanks for the idea!

[chris-schra]

@jmikrut I've sent you a connection request via LI. But to add here: thing is, I'd suggest a new option for creating schemas.

Let's take this as an example

@JSONSchema({
  description: "Rich Text",
})
class RichText extends BaseContent {
  static collectionName: SchemaCollectionName = {
    plural: "RichTexts",
    singular: "RichText",
  };

  @IsOptional()
  @IsString()
  @JSONSchema({
    "ui:widget": "textarea",
    "data:text-format": "html",
    "ui:text-features": ["link", "bold"],
  })
  text: string;
}

export default RichText;

I know this is not really nice, but still ... hm... kind of elegant to describe a data schema.

With the help of some decorator and generator magic, this is what is generated automatically:

{
  "$id": "#/schemas/my-namespace/rich-text",
  "properties": {
    "headline": {
      "type": "string",
      "ui:widget": "textarea",
      "data:text-format": "html",
      "title": "Headline"
    },
    "text": {
      "type": "string",
      "ui:widget": "textarea",
      "data:text-format": "html",
      "ui:text-features": [
        "link",
        "bold"
      ],
      "title": "Text"
    }
  }
}

now we can take the JSON schema and create Payload collections accordingly.

If we combine that with a "SchemaRegistry" (what I did in the first snippet with PayloadCollections const) which holds references to each schema and its collection, we can reference the corresponding type

Sorry, I feel I'm creating even more confusion :D

[MoSattler]

I am also very interested in this. One of the main reason why I was considering Payload for our project was the advertised typesafety. I was assuming that type safe local CRUD functions would be generated (just like Prisma's), but I think that's not the case.

Is anything like that on the roadmap?