Ability to define schemas for path params

[OwenVey]

I have an endpoint like /rankings/:countryCode/players, and I was wondering if it's possible to make the countryCode parameter more specific than just z.string(). For example, it would be great if we could define it like this:

params: z.object({
  countryCode: z.union([z.string('us'), z.string('global')]).default('global').optional()
}),

Currently, even with:

params: z.object({
  countryCode: z.string().default('global')
}),

I get the following TS error

Type 'ZodObject<{ countryCode: ZodDefault<ZodString>; }, "strip", ZodTypeAny, { countryCode: string; }, { countryCode?: string | undefined; }>' is not assignable to type 'ZodObject<{ [key: string]: ParameterSchema; }, UnknownKeysParam, ZodTypeAny, { [x: string]: string | number; }, { [x: string]: string | number; }>'.
  Type '{ countryCode: z.ZodDefault<z.ZodString>; }' is not assignable to type '{ [key: string]: ParameterSchema; }'.
    Property 'countryCode' is incompatible with index signature.
      Type 'ZodDefault<ZodString>' is not assignable to type 'ParameterSchema'.
        Type 'ZodDefault<ZodString>' is missing the following properties from type 'ZodString': _regex, _addCheck, email, url, and 39 more.ts(2322)

I'm not sure if this is a bug or a current limitation of params, but I think it would be a great quality-of-life feature to allow more specific parameter definitions with defaults. I’m also curious how this would work with number types and others, given that everything in the URL ends up being a string. Just an idea to consider!

[Bekacru]

Yeah, the initial intention was to restrict to numbers and strings to avoid assigning to arrays or other types. But, I agree that thta's a valid use case. It's one line change so I'll release a patch with beta tag for now.

[Bekacru]

@OwenVey just released a beta version for this update (@better-fetch/[email protected]). Previously, we didn't validate parameters, body, or query. They were only used for type inference. Now, it should work. Plus params can be any zod schema. Let me know if you run into any issues.

[OwenVey]

Updated to 1.1.5-beta.1, other zod schemas seem to be working great for params now but how would I go about handling optional params? In this case, I'm providing a default so I don't want be forced to pass params in $fetch() every time unless I want to override it. Doing this:

params: z.object({
  countryCode: z.string().default('global'),
}),

works now but the $fetch function still says i need to pass params. Makes sense as that is what my schema says. So then I tried defining params as optional like so:

        params: z
          .object({
            countryCode: z.string().default('global'),
          })
          .optional(),

but then I get a TS error on params stating

Type 'ZodOptional<ZodObject<{ countryCode: ZodDefault<ZodString>; }, "strip", ZodTypeAny, { countryCode: string; }, { countryCode?: string | undefined; }>>' is missing the following properties from type 'ZodObject<{ [key: string]: ZodType<any, ZodTypeDef, any>; }, UnknownKeysParam, ZodTypeAny, { [x: string]: any; }, { [x: string]: any; }>': _cached, _getCached, shape, strict, and 14 more.ts(2740)

In a perfect world, it would be nice to just be able to define my params schema and be able to mark individual fields as .optional() and better-fetch would figure out if I have to pass any params based on if there are any not marked as .optional(). That way I don't have to mark the actual param's z.object({...}) with .optional() but not all sure what's possible here.

Edit: I forgot that zod handles not making things required if .default() is used. My question still stand though on what the best way would be to not require params being passed to $fetch() in that case. Right now I have to do

const data = await $fetch('/rankings/:countryCode/players', { params: {} });

which isn't ideal.

[Bekacru]

Yeah only zod object was allowed for params. try the new release (@better-fetch/[email protected]) it should fix it.

[OwenVey]

Verified it works in 1.1.5-beta.2!