W
Wasp2mo ago
Zeke

Prisma "Includes" Typings?

What's the best way to type a query that returns a Prisma query with includes? I have a lot of nested ones and have changed my schema a few times, so I've needed to update the return type. I'm just using & { includedThing: IncludedThingType }, but that gets messy when nesting the includes. Is there a better way to handle this?
13 Replies
kapa.ai
kapa.ai2mo ago
Hi @Zeke. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
Zeke
ZekeOP2mo ago
:boi:
kapa.ai
kapa.ai2mo ago
---------------------- Wasp currently does not automatically infer or generate precise TypeScript types for Prisma queries with nested includes. When you use Prisma's include to fetch related entities, the return type is not automatically reflected in the generated entity types (e.g., Material, Product, etc.). This means you need to manually annotate your return type to match the structure of your query, especially when you have nested includes. The recommended approach, as discussed in the Wasp community, is to explicitly define the return type using intersection types. For example, if you have a query like this:
return context.entities.Material.findMany({
include: {
products: {
include: {
product: true,
},
},
},
});
return context.entities.Material.findMany({
include: {
products: {
include: {
product: true,
},
},
},
});
You should annotate your function like this:
Materials.GetAllQuery<void, (Material & { products: (ProductMaterials & { product: Product })[] })[]>
Materials.GetAllQuery<void, (Material & { products: (ProductMaterials & { product: Product })[] })[]>
This approach can get verbose and messy with deep nesting, but it's currently the best way to ensure type safety in Wasp when using Prisma includes. There is an open issue to improve this in the future, so hopefully, Wasp will provide a more ergonomic solution down the line. For now, manual annotation is necessary for full-stack type safety when returning nested relations from queries [Discord: Object relation doesn't compile to TypeScript > Answers Part 2]. If you want to avoid this verbosity, you can omit the explicit return type and let TypeScript infer it, but then you lose some of the benefits of full-stack type safety that Wasp provides [Discord: Need help with joined tables > Answers Part 1]. In summary:
- Manually annotate the return type to match your includes. - Use intersection types to describe nested relations. - There is no built-in utility in Wasp (as of now) to automatically infer these types. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zeke, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
Zeke
ZekeOP2mo ago
@kapa.ai what issue is it?
kapa.ai
kapa.ai2mo ago
Let me check the knowledge base for you again. One moment! :books:
MEE6
MEE62mo ago
Wohooo @Zeke, you just became a Waspeteer level 7!
Zeke
ZekeOP2mo ago
🎉
kapa.ai
kapa.ai2mo ago
---------------------- The issue related to improving type safety and ergonomics for Prisma queries with includes in Wasp is discussed in the context of full-stack type safety. Specifically, the challenge of having to manually annotate return types for queries with nested includes is mentioned in a Discord support thread, but there is no explicit GitHub issue solely dedicated to this exact problem in the provided knowledge sources. However, related issues include: - Fix Full-stack type safety type names: This issue addresses regressions and improvements in type names for full-stack type safety after Prisma upgrades. - Expose Prisma types as Wasp imports: This issue discusses making Prisma-generated entity types available for both server and client, which is related to type safety for queries and actions. - Full-stack type support for Queries and Actions: This issue aims for Wasp to automatically type everything about a Query or Action, including return types. While these issues are related, none of the knowledge sources explicitly mention a dedicated issue for automating or improving typings for Prisma includes in Wasp. If you are looking for a specific issue to track this, the closest would be the general full-stack type safety issues above, especially #1570 and #910, but the knowledge sources do not confirm a more targeted issue at this time. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zeke, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
Zeke
ZekeOP2mo ago
k, so then there isn't an issue about it 🤦‍♂️
Zeke
ZekeOP2mo ago
GitHub
Better handling of Types for Prisma "Includes" · Issue #2942 · wa...
When including multiple/nested entities in a Prisma function, it gets tricky to make the return type for that query. I&#39;m not sure how to better accomplish this (generic types? using &quot;typeo...
miho
miho2mo ago
Have you tried using the satisfies Typescript keyword?
miho
miho2mo ago
Queries | Wasp
We'll explain what Queries are and how to use them. If you're looking for a detailed API specification, skip ahead to the API Reference.
Zeke
ZekeOP2mo ago
didn't know that was a thing, thanks! I should really spend some time learning more typescript 😅

Did you find this page helpful?