In some cases, ideal sql values naming can conflict with js values, that is to say that for obvious reasons we currently rely on things like
// Not allowed
// const true = sql<true>`true`;
const tru = sql<true>`true`;
At the moment, conflicting names are resolved by using arbitrary strategies, this can lead to an unintuitive DX. Moreover, having a clear consistent syntax for sql values could help users spot them through code, and adopting a prefix-approach could let users rely more efficiently on auto-completion to figure out available values.
In light of this, it could be beneficial to adopt a prefix syntax, something like:
const $true = sql<true>`true`;
A foreseeable caveat is that we opt for a syntax that ends up conflicting with some framework-specific preprocessor (ex.: svelte's $ syntax for stores although this doesn't matter as it's geared towards client-side reactive code unlike drizzle's server-side target, and is soon to be deprecated with svelte 5...)
In some cases, ideal
sqlvalues naming can conflict withjsvalues, that is to say that for obvious reasons we currently rely on things likeAt the moment, conflicting names are resolved by using arbitrary strategies, this can lead to an unintuitive DX. Moreover, having a clear consistent syntax for
sqlvalues could help users spot them through code, and adopting a prefix-approach could let users rely more efficiently on auto-completion to figure out available values.In light of this, it could be beneficial to adopt a prefix syntax, something like:
A foreseeable caveat is that we opt for a syntax that ends up conflicting with some framework-specific preprocessor (ex.: svelte's
$syntax for stores although this doesn't matter as it's geared towards client-side reactive code unlike drizzle's server-side target, and is soon to be deprecated with svelte 5...)