Hey 👋
This has been requested since the early days. Personally, I feel this might be redundant in 99.999% of cases, but there are probably some cases where this could help cover blindspots and help ship complex dynamic/composed queries confidently.
Another benefit is with narrowing the output type via a standard schema instead of manually with $narrowType and maybe lying to the compiler and to downstream if things don't align at runtime. Think of, narrowing and validating that what looks like a regular string in codegen, is actually an application-side enum value.
Another benefit is result transformation in-chain, e.g. hydrating that string result column to a native Date.
It needs to yell at you when you pass a schema where its input type doesn't match the query's output type.
It needs to support standard-schema, not a specific library, not zod-specific. It should not add a non-dev dependency. It should not require consumers to install a standard-schema package.
It could look like (please don't use it for such a simple query!!!):
import { z } from 'zod'
enum PersonStatus {
ALIVE = 'alive',
DEAD = 'dead',
IN_COMA = 'in_coma'
}
const personSchema = z.object({
id: z.string().uuid(),
email: z.string().email(),
createdAt: z.string().transform((value) => new Date(value)),
status: z.nativeEnum(PersonStatus),
})
const results = db
.selectFrom('person')
.selectAll() // output type is { id: string; email: string; createdAt: string; status: string; }[]
.$parse(personSchema) // output type is { id: string; email: string; createdAt: Date; status: PersonStatus; }
.execute()
Should we do it? is it the responsibility of a query builder? Unclear.
I don't like the part where people will overuse it for even the simplest queries that don't need any schema, and not only for specific transformations and narrowing use cases.
I don't like that it might give people the wrong idea about type-level safety, and will make some maximalist redditors falsly think that Kysely is not type-safe.
Hey 👋
This has been requested since the early days. Personally, I feel this might be redundant in 99.999% of cases, but there are probably some cases where this could help cover blindspots and help ship complex dynamic/composed queries confidently.
Another benefit is with narrowing the output type via a standard schema instead of manually with
$narrowTypeand maybe lying to the compiler and to downstream if things don't align at runtime. Think of, narrowing and validating that what looks like a regularstringin codegen, is actually an application-side enum value.Another benefit is result transformation in-chain, e.g. hydrating that
stringresult column to a nativeDate.It needs to yell at you when you pass a schema where its input type doesn't match the query's output type.
It needs to support
standard-schema, not a specific library, notzod-specific. It should not add a non-dev dependency. It should not require consumers to install astandard-schemapackage.It could look like (please don't use it for such a simple query!!!):
Should we do it? is it the responsibility of a query builder? Unclear.
I don't like the part where people will overuse it for even the simplest queries that don't need any schema, and not only for specific transformations and narrowing use cases.
I don't like that it might give people the wrong idea about type-level safety, and will make some maximalist redditors falsly think that Kysely is not type-safe.