Passing Context for Dependency Injection
Is there a standard pattern for passing the context object for database interaction to functions?
When using Prisma, I can always pass the Prisma client to another function and have full type suggestions. when using wasp, routes are given a "context" object with an array of accessible entities that are defined in the wasp definition.
is there a way to pass around the context object with typing to other functions in the same way that is possible with standard Prisma?
wasp: version: 0.13.2.
WSL2, Ubuntu 22.
4 Replies
Hi @Kantros. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Yes, there is a standard pattern for passing the context object for database interaction to functions in Wasp. The context object is automatically passed to your operations (Queries and Actions) and APIs by Wasp. This context object contains user session information, as well as information about entities.
When you define an operation or API in your
.wasp
file and specify the entities it uses, Wasp will inject the specified entities into the operation's or API's context argument, giving you access to the Entity's Prisma API.
Here is an example of how you can use the context object in a Query:
In this example, context.entities.Task
exposes prisma.task
from Prisma's CRUD API.
You can also use the context object in an API:
In this example, context.entities.Task
also exposes prisma.task
from Prisma's CRUD API.
As for passing the context object to other functions with typing, Wasp currently does not have full type support for the context object. However, there is ongoing work to improve type support in Wasp, including for the context object and operation arguments (source (https://github.com/wasp-lang/wasp/issues/975)).
For more information, you can refer to the following documentation:
- Working with Entities (https://wasp-lang.dev/docs/data-model/entities#working-with-entities)
- Using Entities in Operations (https://wasp-lang.dev/docs/data-model/operations/overview)
- Using Entities in APIs (https://wasp-lang.dev/docs/advanced/apis#using-entities-in-apis)
- Implementing Queries (https://wasp-lang.dev/docs/data-model/operations/queries#implementing-queries)
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Kantros, 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?If you really need
prisma
you can import it from import { prisma } from 'wasp/server'
and you get all the benefits as you usually do 😄
Could you maybe share some code with us so we can understand better what do you need? We'd like to learn!sure, basically I have a function:
which checks the database to make sure I'm not inserting duplicate data into the database which holds a subset of data from an external large dataset.
Currently I am creating a nested function so that the context is in scope, which is not clean or reusable. importing the full Prisma client is acceptable, and I saw it in the docs, but I wanted to make sure there wasn't a "wasp way" of approaching the problem. Thanks for responding!
For some use cases you need to go beyond Wasp's abstractions and that's okay 🙂 We are learning to balance the "ease of use" and "freedom of use" while building Wasp and these escape hatches like
prisma
proved to be crucial in making Wasp useful