Theo's Typesafe Cult•13mo ago

Array<string> vs Record<key, true>?

So, this is a call for mental help lol. First this is a taste question, is not a necesary question and is clearly a dum question, but i wanna ask any way. In my lastest months i been working usually in backend stuff, and primary using Prisma for schema and some queries, because is VPS not serverless, Kysely for some complex queries, and Zod for validation (DTO and others stuffs). All is good, everything work perfectly (ignoring the lack of some query functionalities in Prisma). But there is something that really BOTHER me when i read the code. For example when picking fields in a prisma query, you do a something like this:

const query = await prisma.user.findMany({
  select:{ id: true, name: true, last_name: true }
})

const query = await prisma.user.findMany({
  select:{ id: true, name: true, last_name: true }
})

This kind of API is truly intuitive, feels nice. But then using Kysely is something like this:

const query = await kysely.selectFrom('User').select(['id','name','last_name']).execute()

const query = await kysely.selectFrom('User').select(['id','name','last_name']).execute()

This also feels nice, but when the query grow too much, usually when conditionals are added or too much select fields added, i feel that the kysely way it feels more verbose. Another case is validation library like zod, i really love zod, too much hahaha.

zodDataSchema.pick({
    name: true,
    hello: true,
});

zodDataSchema.pick({
    name: true,
    hello: true,
});

Again, they use the Record<key, true> approach to pick/omit/required/partial objects, just like prisma does. But then most utility libraries like lodash, or remedajs use Array<string> approach, this make me create my own libraries to have similar approach to Record<key, true> approach

//Remeda js way
const remeda = R.pick(data, ["age", "isAdmin", "name"]);
//Example custom zod way
const custom = util.pick(data, {
    age: true,
    isAdmin: true,
    name: true,
});

//Remeda js way
const remeda = R.pick(data, ["age", "isAdmin", "name"]);
//Example custom zod way
const custom = util.pick(data, {
    age: true,
    isAdmin: true,
    name: true,
});

So, my question is, is healthy and good that i wanna choose only one way of doing picking/omit in objects? I been building my own alternatives to Remeda or Kysely but Record<key, true> approach, what do you think? Do you like it? I'm just testing.

11 Replies

oljimenez•13mo ago

Let me clarify that in the Kysely approach, i'm not recreating Kysely from scratch, this is just a test functions and clases that wrap kysely API to give this Record<key, true> API and still work on progress. I'm not so crazy to try to rebuild kysely myself alone lol.

jackmcbride_98•13mo ago

Seems a little obsessive to me. Could you make a wrapper around kysely that basically does things in the way prisma does and then maps it to kysely?

oljimenez•13mo ago

i don't know yet if i can do everything that kysely does, but i already did some basics stuffs, is a work on progress (like i showed in one of the pictures). My point with this question is that, it feel hugly to have differents APIs for all my cases, Prisma -> Record based, Zod -> Record based Kysely -> Array of string based Remedajs -> Array of strings based It feels ugly to have so different APIs for this similars things in only single codebase.
One advantage of having the same kind of API in all proyect codebase, is copy and paste. This is why i love prisma and zod working together, because i can copy and paste select statements so ez. But yeah, is clearly obsessive from my part, that's why i'm asking 😂

jackmcbride_98•13mo ago

I get why you don't like it, what are the use cases that prisma doesnt support? Perhaps you can find another way round it or make a PR to the library to support it

oljimenez•13mo ago

Prisma don't support aggregate functions with conditions on relations, example, Select all clients that have an order count > 8, or sum order.total_price > 200

jackmcbride_98•13mo ago

Would you be able to do it in seperate queries? I know thats a pain, but might be a bit easier than using kysely and rebuilding it in a prisma way XD

oljimenez•13mo ago

yeah, but is hard to make those findMany in two queries, because i would have to omit pagination for the first query and ended pulling thousand of records or more just to do another filter and then manually grouping, with Kysely is way simpler and clearly more performant, but yeah, it break the same feel of using prisma like for everyting I could try to make PR for prisma to fix those issues, but already exist issues/proposals that suggest this in their repo from months or years and they/anybody haven't fix them, so maybe is not easy to do, maybe i'm wrong.

oljimenez•13mo ago

https://github.com/prisma/prisma/issues/8935

GitHub

Search by relation count eq | gt | lt · Issue #8935 · prisma/prisma

Problem I think the issue should be related with #3821 model Topic { id Int @id @default(autoincrement()) title String @db.MediumText content String @db.LongText voters VotersOnTopics[] watchers Wa...

oljimenez•13mo ago

a year without fixing. I really give up, excepting that the Prisma Client would be fixed in any time soon, that's why i choose Kysely, is better, more control and features, but is more verbose in my opinion, that's why i was trying that wrapper idea

jackmcbride_98•13mo ago

Fair, you could have a go at creating that feature in the Prisma codebase, or just accept that you'll have different syntax for some queries. I've heard good things about kysely, could also just switch over to that if its better

oljimenez•13mo ago

yeah, currently i'm using both, and in this proyect i won't chage that, but i'm trying to build/PR something to fix this ''code style issue'' so in the future i could use both in similar ways or even use kysely always.

Gaming

Programming

Array<string> vs Record<key, true>?