Infer type from zod / narrowing type down to string and undefined

[BengtHagemeister]

Hi,

is it possible to narrow down an input string to the types string and undefined and NOT null?

Example: Title should be allowed to be undefined (not required) but should not be allowed to be null (because of how prisma handles null and undefined).

With zod this is possible by using the schema: z.string().nonempty().optional() which infers down to:

type User = {
    title?: string | undefined;
}

In giraphql this will prohibit the user of submitting null by returning a validation error but the type of title is still <string | null | undefined>.

const EventUpdateInput = builder.inputType('EventUpdateInput', {
  fields: (t) => ({
    title: t.string({ validate: { schema: z.string().nonempty() }, required: false }),
  }),
});

Thanks!

[hayes]

Unfortunately, there currently isn't a good way to narrow the types. The validation plugin currently does not have the ability to change the types for a field. This basically comes down to there not being a way to inject an extra generic into the signature of the t.string method that could be used to infer the schema shape and to use that to overwrite other generics used by that method.

If this is an important feature, one way we could achieve this is the create a new builder method (t.validatedField({ type: 'String', validate: {...}}) or something similar), that has the ability to infer an extra generic, and narrow the type correctly.

[BengtHagemeister]

It would declutter the code quite a bit. My problem is that I want to allow people to only update parts of a resource (hence omitting otherwise required values). But since giraphql also allows null when required: false I need to check for every null value when submitting too prisma to ensure that it's not removing the value but skipping it. Or am I missing something obvious that could fix this problem?

[BengtHagemeister]

I just figured that my sentence above: In giraphql this will prohibit the user of submitting null by returning a validation error but the type of title is still <string | null | undefined>. seems to be incorrect. Even with this validation code it will allow me to submit null. Is this on purpose?

Maybe it could be an option to add another property nullable beside required. That only prohibits using the value null but not making it required.

const EventUpdateInput = builder.inputType('EventUpdateInput', {
  fields: (t) => ({
    title: t.string({ required: false, nullable: false }),
  }),
});

(The difference between the value null and omitting a value seems to be a common problem in graphql graphql/graphql-js#1298 (comment))

[hayes]

I've got some ideas on how to do this in the future, but it won't be fixed for a bit. There are some typescript limitations, that make the obvious solution complicated, and some breaking changes required to be able to implement some of the other solutions I have in mind. I'm going to be working on a 4.0 release soon that will enable some new patterns in plugins that should help with this.

Basically, field and type refs need to be redesigned so that I can more easily create chain style apis, which isn't currently possible . The goal would be to be able to do something like: t.field({...}).validate(...) and have the validate call refine the shape associated with the field. This would also allow something similar for input types: const MyType = builder.inputType({...}).validate(...) which would have a type refined by a zod schema passed to validate.

The issue is that the refs returned by SchemaBuilder and FieldBuilder methods don't have a reference to the builder that created them, and can't access/modify the configs associated with them. Changing this won't affect users much, but is still a breaking change for plugin authors, and users who import some of the types/classes for other reasons.

Because this is a breaking change, and there are a number of other breaking changes I have wanted to make for a while, this work will likely need to batched with a bunch of other changes into a single release, meaning it will take some time to get it all released.