"This accepts type of undefined, but is required at runtime"

[medihack]

In some generated code the following schema is used to validate some query input:

const Get__ModelName__ = z.object({
  // This accepts type of undefined, but is required at runtime
  id: z.number().optional().refine(Boolean, 'Required'),
})

Can someone explain to me why id: z.number() is not enough here? Unfortunately, I don't fully understand the comment above that statement.

[flybayer]

Good question.

On the frontend, result of useParam type is number | undefined. So somehow we need to get the number | undefined type to work with the query input. One way is by marking the zod schema as optional. The other way, is keep zod schema as just z.number() and on the frontend have the query input as {id: userId!}. The ! character will override the TS type to remove | undefined

[dbachrach]

@flybayer

I was looking back into this and I'm wondering if adding something like this would make sense:

import { useParam } from "blitz"

export function useParamStrict(key: string): string | string[]
export function useParamStrict(key: string, returnType: "string"): string
export function useParamStrict(key: string, returnType: "number"): number
export function useParamStrict(key: string, returnType: "array"): string[]

export function useParamStrict(
  key: string,
  returnType?: "string" | "number" | "array"
): number | string | string[] {
  const value = useParam(key)
  if (!value) {
    throw new Error("Param is not found") // Or some specific new blitz Param Not Found Error Type
  }
  return value
}

For Dynamic Route params they should always be defined. So by adding a strict version of useParam you can get a non-nullable type back and not have to bother with ! or making your queries/mutations accept optionals.

Let me know if there is a scenario I am missing though.

[dbachrach]

I should also add another option I have been trying, which uses zod to validate. This can both solve the non-nullable case or more complex cases like parsing a param into an enum:

export function useParamZod<Schema extends ZodSchema<any, any>, Type = zInfer<Schema>>(
  param: string,
  schema: Schema
): Type {
  const input = useParam(param)
  return schema.parse(input)
}

// Then use it:
const myParam = useParamZod("myParam", z.string())

[flybayer]

@dbachrach unfortunately that will break static prerendering. If you run blitz build with that code, it will fail (I'm 99% sure). The params are empty during static pre-rendering because there is no http request. It's essentially generating a static "loading screen" that every request to that route can use regardless of the param.

And because of that, the very first render on the client will also have params empty because the first render must match the static html. Otherwise it will cause a React hydration error.

We automatically handle this inside useQuery by waiting to fire off the network request until the second render.

[dbachrach]

Ok interesting. Yes I can replicate what you are describing now but I have to remove the suspense boundary that I have in _app. With the suspense boundary this code works fine. I wonder if it would be useful to add the same behavior that useQuery has into this useParamZod as well. The reasoning being that if you are going to fallback to a loading spinner and essentially bypass the prerendering of your component, then might as well remove the nullability since that case doesn't really matter.

I can look into this more if you think this is worth pursuing.

[flybayer]

@dbachrach ok yeah, I think a useValidatedParam('myParam', z.string()) hook could be a good addition. It just needs to respect router.isReady, and probably it should use suspense by default with ability to disable (same as useQuery)