Guidance to create a generic wrapper over Kysely
I am trying to create a generic authentication wrapper over Kysely. The idea is
- You can pass some config to this function, which includes a reference to
Kysely
instance, a database table name and an array of column names.
- The function will return an authenticator instance you can use to perform user lookups during Login. The internals of this function are not important for this discussion.
This is what I have so far. You can copy/paste the following code to run it yourself.
The .where(config.uids[0])
method call gives a type error saying, "The Columns are not assignable to the input accepted by the where method".
So, I need some guidance on which approach to take for this use case.7 Replies
It's very hard or impossible to write generic wrappers like this for kysely. Kysely's super strict typing doesn't work well with generics. Even if you managed to get this working with some insane type gymnastics, the next version would probably break it.
Ahh okay. Thanks for your reply 🙂
You'd jump through hoops making this viable, and it'll look pretty ugly and not type-safe under the hood due to how specific kysely is and typescript's limitations - but you could probably make a decent user experience still. and could lock to a specific kysely version.
I have another use-case, lemme ask you guys before I give up on this one.
So, here I am trying to create a generic
firstOrCreate
helper function. This is how the implementation looks like so far.
I can execute the function with no errors.
However, the eb.and(searchAttributes)
method call gives an error
---
Is it too much to ask from Kysely internals to work with generic functions like this?
Or you think it can work?Here's the error screenshot
@virk The error you're seeing is due to a common typescript limitation. You cannot have both generic helpers and type-safety within them when using something specific as a kysely method.
DB
is anything and TB
is just a string in your function's context, so anything you put in eb.and
is just too wide and not assignable to the expected types.
Your function is still type-safe, autocompletion friendly and produces the same SQL as long you got arguments and return type covered - which is what your consumer cares about. The internals cannot be type-safe - you must escape it with searchAttributes as any
- which is what you care about.
Using db.selectFrom(table) as SelectQueryBuilder<any, any, {}>
can reduce amount of as any
downstream.Hey, thanks for the reply.
Cool, just wanted to make sure I am not shooting myself in foot by typecasting to any