Correct Server Actions Design using Prisma?
Unanswered
RW posted this in #help-forum
RWOP
See the video for an overview of the functionality I'm trying to achieve. It's just a filterable data table.
Slider/dropdowns use callback prop to call a server action
I feel like my current design of the server actions (
Main focus are the functions:
-
-
-
Slider/dropdowns use callback prop to call a server action
getFilteredStats(), passing the filter states as params. The result is passed directly to a datatable component.I feel like my current design of the server actions (
actions.ts) is very clunky and probably doesn't aggregate the data very elegantly at all. I feel this way because I'm still having to use JS after the Prisma query to aggregate the stats. It doesn't feel like idiomatic JS. Could someone review? Any help would be appreciated.Main focus are the functions:
-
getFilteredStats()-
getEliminationsByPlayer()-
getDamageDealtByPlayer()3 Replies
Greater Shearwater
Server Actions are not for fetching data. They are for data mutations.
For fetching use the Server Components.
Ideally what would happen hear is, your dropdown updates the URL search params. You can read those search params in your Server Component and query the database using the values.
For fetching use the Server Components.
Ideally what would happen hear is, your dropdown updates the URL search params. You can read those search params in your Server Component and query the database using the values.
RWOP
Maybe that's what I'm already doing then and I just confused the names and misunderstood what a server action is. I do have a
What are the advantages of that design in particular? If possible, I'd like to just stick to the current unless there are any major downsides. For example if I have other interactive components on the page, then how will they both update the URL search params?
I'm more so just trying to see if the way in which I query the DB using Prisma is proper and scalable. Eventually, there will be more than just damage and eliminations (potentially dozens of stats).
"use server" at the top of lib/actions.ts so it's a server component afaik? What are the advantages of that design in particular? If possible, I'd like to just stick to the current unless there are any major downsides. For example if I have other interactive components on the page, then how will they both update the URL search params?
I'm more so just trying to see if the way in which I query the DB using Prisma is proper and scalable. Eventually, there will be more than just damage and eliminations (potentially dozens of stats).
Greater Shearwater
Maybe that's what I'm already doing then and I just confused the names and misunderstood what a server action is. I do have a "use server" at the top of lib/actions.ts so it's a server component afaik?Not really. What you have here is a Server Action. That's what the
"use server directive marks. Those functions in that file are functions that runs only on the server but you can call them from the client as well. Basically those are like endpoints, but for POST requests. If you call a Server Action and check the Network tab of your browser dev tools you will see the request type is "POST".Server Components on the other hand are React Components. They also run only on the server, and also they can be async components, unlike Client Components. Because of that you can directly fetch data inside them, either by calling an API or directly querying the database using Prisma.
I didn't check in depth, but just by scanning through the Prisma queries they seem fine to me. Plus from the video things seem to work fine right?
I would just move the data fetching into Server Components, rather than having them in Serer Actions. It shouldn't be much work since you already have the Prisma queries.
I suggest reading through these two doc pages. It explains lot of these. Also have examples with ORMs (like Prisma) as well.
https://nextjs.org/docs/app/getting-started/fetching-data
https://nextjs.org/docs/app/getting-started/updating-data