is it bad to write to database in .query()
I do get confused sometimes i write my
ctx.prisma.user.create({...})
In a .query()
Instead of .mutation()
73 Replies
Yeah, use .mutation() instead
useQuery defaults to true to a lot of refetch options, so you wouldn't want that unless you're actually getting data that you want to display and persist state between client and server
I am talking of the server side not client side
Generally queries are idempotent while mutations don't have to be and thats the pattern react query encourages
at the end of the day everything is just functions
but you'll really have to bend react query to not shoot yourself in the foot by doing this
and it will make anyone who reads your code hate you
Why are you doing this server side?
I don't understand what you mean
On the server you define .query() or .mutate() yes, but you actually have to .useQuery() or .useMutate() on the client
or this
Yeah but you're calling this from the client side, aren't you?
You have to use .useQuery() on the client side
Or .useMutation()
And then do .mutate()
can i ask why you want to mutate in a query
my question was based on server not client
why not just do it in a mutation
Anything you change in the server will affect the client though?
nothing really just that i get mixed up sometimes just wanted to know it has any issues if its done that way
This is what I'm trying to explain though? Hahahaha
the issue is that queries by default run on every page load or even more frequently than that
so you're putting shit in your database all the time when you don't want to
mutations only run when you mutate them
If you do .query() and then .useQuery() on the client side, you'll have a bunch of refetch options enabled by default
oh i am getting your point
but then both usequery() and useMutaion() accepts inputs
Yeah of course
That's up to you
on the backend side, queries and mutations are just functions that take input and then do stuff
but like the point is that you call them with useQuery and useMutation, and those are very different things
no i didnt ask on this
it was just based on the server
Bruh
well if you just make a server and then never call the stuff on the server
you can just ship an empty file and it's the same
your still not getting the point😅
but then you can still use
.query()
.mutation()
on same instance
yea sure have a nice day
@Lopen32 You asked whether to use .mutation() or .query() in the backend, right?
yes when i want to write to the database
Ok
So where are you calling this tRPC procedure from?
??
i just wanted to know if using .query() is bad
That's not the point though
Where are you calling the function?
i use .mutation() normally
server/trpc/router
Like from your client side?
How are you calling it
When you use .query() for example?
Okay great!
So this is where the difference is my friend!
If you use .query you need the .useQuery() hook on the client side
And this has a ton of refetch options on by default
Right?
This thing will automatically try to update the data that comes out of it
not update it creates
useQuery() will try to refetch the return
So in this case you're just returning status and message
This is why . query() is bad here because it will trigger by itself and cause side effects
Like you said, creating an account or whatever it is
On the other hand, if you use the .mutate and . useMutation() hook, you get a mutate function on the client side that you can explicitly call only when you want to create an account
do you know when this runs, and how often?
once
oh nice thanks for this explanation
are you sure it runs once?
Something like this pseudo code:
And then you can call createSomething() explicitly only when you want to do this
click outside of the browser and then inside of it again
check your network tab
yes
Lopen, if you can
Read what I wrote
If it doesn't make sense, search up react query and go to docs
Or here
Ctrl+f "refetch"
And then look at this
i usually do it like this
I hope that helps!
Be careful, mutateAsync has some pitfalls
Make sure to understand it's a promise
I'd do mutate
And if you need to do something when it succeeds
For example with the status
Use the onSuccess/onError callbacks
try catch block not enough?
please read through the react query docs
this is a pointless conversation otherwise
okay
@cje It's difficult to understand in the beginning, it's okay
It took me a while to wrap my head around this
@Lopen32 just experiment a little and you'll see the difference, just be careful when you're doing auth
Why not use next-auth?
this is the page you want https://tanstack.com/query/v4/docs/quick-start
Quick Start | TanStack Query Docs
This code snippet very briefly illustrates the 3 core concepts of React Query:
Queries
then go on to read more about whatever parts you care about
i use next auth
next auth is for sign in
not sign up
Oh okay, I didn't know that for Credentials!
Why use Credentials?
formaility
All right! Best of luck!
Also, if you're ever iffy on how to use tRPC, you can always just use the api folder of NextJs
And then use fetch('POST') on the frontend
If anything
??
What?
that means i will start writing api ?
API Routes: Introduction | Next.js
Next.js supports API Routes, which allow you to build your API without leaving your Next.js app. Learn how it works here.
You can write endpoints there and just use fetch() regularly
i have used next api
not an option
Oh, why not?
thats why i chose trpc in the frist place
else will use express
tRPC just provides type-safety
And it uses react query under the hood
I'm saying if react query ever gets complicated you can just use the api folder and have handlers there
Why would you use express?
industry standard
and i just dont like graphql
No I'm asking, why do you think you have to use express if you use API routes?
nothing really just familiar with it
are you using the create-t3-app?
Yes
where are you declaring your queries & mutations?
server