_Look at this sublte inclusion of type safety , the tasteful thickness of it._ *Oh my god!* _It even has the loading and error states handled by react-query._
@@joshtriedcoding how long has your channel been up? It seems like you've just discovered react-query and talking about it like it's something incredible. It's silly and funny at the same time (I think that's what the guy was trying to say, it's called sarcasm)
Great point, but his example makeRequest function that he was replacing as a POST request, so the useMutation hook is what should be used instead of that. However yes, the terminology being used is confusing - for getting/fetching data, you would usually use a GET request, or if using react query, you might use the useQuery hook. That being said, there are cases where it's acceptable to use a POST request to fetch data.
react query has a hook called useQuery which is the one to use for fetching data. useMutate is supposed to be used only for mutating/changing data, ie create/edit/delete.
Exactly..… he should have used useQuery on the client and use the await prefetchQuery on the server component and wrap the component consuming the data in a hydration boundary
Hi Josh. My main problem with this approach is data consumption and download speed / execution time, which may or may not be a concern depending on where you operate. I'm currently working for a client in Zambia and Malawi which is known for their expensive data and lack of network availability, so everything counts. As a test, I made both server action and /api route return the same payload ({foo:"bar"}}, both using POST (a restriction of server actions) and there are the results: - server actions - 447B download size - 84ms to respond - /api/ route - 192B download size - 25ms to respond As the request in server actions points to the route itself it's likely running much more code than the /api route which just returns some JSON. That said 100% agree this is a much better DX with types flowing through and love to see new and creative approaches to current problems!
Mutations are meant to be used for creating or altering data -- i.e to mutate it., not for fetching data. Fetching data should use useQuery. POST, PATCH, PUT requests should use useMutation.
instead of using react-query I would just implement a custom hook for the project that reduce redundancy and track request state. You can make it typed for typescript easily with a generic function, like
Amazing! Thanks to this video I went from Apprentice Brick Layer to Senior-Seasoned Full-Stackoverflow-BackToFront-End Devengineer and ready for retirement.
Sometimes you want to perform a GET request when a user clicks a button for example. You can't really control when a useQuery runs unless you specify the enabled property
@@outis99 There are ways to do that from query (if i'm not mistaken). useQuery exports a "refetch" function for that. We can also invalidate the specific query key using queryClient (useQueryClient). And there might be other ways. I might not be right about this, but as far as i know, mutate are intended for post, put, etc. If anyone has a deeper understanding about react-query, i'm here to learn :D
@@StabilDEV I guess what he means is that with useQuery the query performs when the component is mounted and if yout want to controll it yout need to pass the enabled property and use refetch but with useMutation you just need to use the mutate function.
@@josepazmino842 yes, but the reason hes using useMutation is not for this reason. Like Stabildev said, all server actions are post so you can't use useQuery.
server actions are not made for fetching data, for this case better use "server only", (it is not provided by default). Basically you can achieve the same using native fetch and built in loading, suspense, error boundary. The big difference is because you use a hook, you are not more purely on server side, this require directive "use client", but your approach is much cleaner.
Unlike queries, mutations are typically used to create/update/delete data or perform server side-effects. For this purpose, TanStack Query exports a useMutation hook. That from react-query documentation
Hey Josh, I definitely like this approach but the NEXT team are saying "handle form submissions and data mutations" and i have seen around the internet to not to use for as "GET" use only as Mutation function and so, What are your thoughts on this. Is it really a thing to use only as a Mutation or we can do whatever inside it without worrying about these things?
I’ve tried using actions for getting data. Went back to using usual fetch. Reason? Server actions are executed sequentially, they can not run in parallel. And any other user interaction will be blocked until action is done. This has a huge impact on performance😕 Also, POST requests don’t really have the caching benefits of GET requests
If you want to know the type when using useQuery or useMutation, you can just define the type on that like useQuery() then data must be Response | undefined type so you dont need to use server action on that.
I am still not fond of writing back-end code with Next.js. I simply do not see it becoming manageable as the project grows in size and complexity. It seems to be more suitable for a small-scale project, such blogging, with minimal logic, where using a large-scale framework, such as .NET or Spring Boot, would indeed be an overkill. Furthermore, I followed the official tutorial from Next.js' website and there they even wrote SQL code, an approach that reminded me of when I started learning how to code with PHP, and I would write SQL, PHP, and HTML all together. It was about 10 years ago or so. A simple CRUD, tops.
Hmm why tanstack query isn't typesafe (btw why use useMutation for plain fetching?) ? You can specify types for response where you set up your API handlers/ query functions (and by sharing type declaration across front and beckend you can get typesafety if you wnat/need across both project even if they are separate)
I think it's meant to be a post request but getUser is a bad example for that. Also like you said, you could just specify the data type returned by the fetch request as a typescript interface, so this seems like he's demonstrating a benefit that isn't actually a benefit unless he's assuming we are working with JavaScript and not TypeSrcipt I guess
But then you have to create your own types when the code is already giving you the types. This method gets the types from the code/libraries. However the downside of this method, like you mentioned, is it uses only post requests(server actions are only post req) which don't cache. If you want 'type safety' either use trpc, server components, or validate with zod. This is mostly a dx issue anyways, your method works fine if done properly.
You can wrap ReactQuery hooks inside of your own custom hooks, then you can get type safety and any additional business logic, or statuses you need before returning to the page components. I will keeping using this pattern + api routes for now, still not seeing benefits from server actions, and it is a lot less intuitive to use.
I like the idea, but why would you use a mutation function to get data? Why not use the useQuery hook to get the data in that example? Apart from that the idea is very good!
@@fitimbytyci345 You're doing it right in this case, but don't forget mutations when the data will be created/updated/deleted with users actions, it's easier to implement optimistic updates with it.
You can also add a type to the useMutation like useMutation It seems like the reason this works in the video is because typescript can infer the types from the getUser function you defined. Still a nice pattern! Thanks for sharing!
This is great, I’ve been using this. Once you need to protect the mutations, schema validation or some kind of middleware, I’ve found trpc to be the best option. You can call trpc mutations in server actions. If you’re not using react query, then next-safe-action is a good choice
I guess the only "drawback" is that it only works in client components, since it's a hook. But still a pretty great solution, I absolutely love react query!
@@redeemr does this mean you must maintain the same tags on the Tanstack Query side and Server Actions? How does this look in practice, to minimize the need to manage 2 caches?
@@teeldinho471 Well, you could just not use Next.js cache, passing "no-store" to your fetchs or using some lib that doesn't depend on fetch like Axios to make requests.
I mean that's by design, POST request shouldn't be used to GET a resource which I would expect to be cached Edit: saw the other comments and understood what you meant, yep bad approach
what benefit does "use server" directive have in getUser function? what if instead of making it a server action we made it a normal function without "use server" directive?
Do you typically separate out your server actions into separate files or just include them all in an "actions.ts" file? I'm curious how you prefer to structure your files/folders in general, I'd love to see a video on that at some point!
Also interested. Currently I have my actions in /server/actions with each being grouped somehow if possible. Grouped based on table names or something. But I've seen one file and I've seen a single actions.ts in the same directory as the page using that action
I have a problem, if you want to handle errors, in Server action directly throw errors in development mode can, But in production mode the error message will be hidden, how to solve?
If you don't need caching or invalidation you can even invoke the server action within a custom handler without using RTK mutations, but you have to set a custom loading state, which kinda sucks tho. Also there's some weird errors that occur on the form html element when using server actions directly on them, which is really annoying. So yeah. Invoking actions inside handlers/useEffect or simply react query is much more preferable.
This looks great! However, doesn't react query provide support for typescript using generic types? I personally love extracting every useState and useMutation with fetching logic into separate hook, which take as a parameter the query options object (which also has special type provided by react query), therefore making those hooks highly reusable across many different components due to their customizability.
Tan stack query hooks actually do a pretty good job inferring types, in some special cases you might need to pass generic parameters for type safety, but you can definitely use them without the server action combination.
Pls someone tell me the right way to fetch data in server components. I currently fetch directly from my db on the server side but I noticed there’s no caching.
I think that server actions are called sequentially and not in parallel by Next (since that is considered to be most appropriate for mutations). So, this pattern might introduce really bad client-server waterfalls and lead to poor performance.
Possible. Especially if used in combination with cookies for authentication so you can fetch the current session anywhere on the server. But also im realizing that server actions are executing sequentially and not in parallel. What do you think?
Didn't know react query works with server actions, that's great! Only downside is, server actions are always POST, which doesn't make much sense. I mean, you can get data on the server, but if you're using react query and want to have any sort of dynamic loading going on, you'll still need GET endpoints for actual queries. I mean, maybe not *need*, but I refuse to ever fetch data with POST. I'd honestly stick to the default verbose server actions (maybe wrapped behind a custom hook) if only they stopped using FormData. That api has been growing on me, but I really don't want FormData.
While not sure about react query, RTK query does give the ability to add types for both response types and query args with all the isLoading, error, etc states
I fucking love you, been stuck with fetching api because of cors or wtf that was and the route method was not working, decided to sleep, after 4 hours and BAM in the morning watched your vid and it worked, ty,
This approach makes sense with mutations, but how would this work with fetching a query? afaik 'data' in useMutation works differently, it is "the last successfully resolved data for the mutation", and since it doesn't make sense to call 'mutate' on a query, how do you get the data? I would love to have a similar approach for simple GETs, that doesn't involve using server components and giving up on react-query and its loading state management
It works the same, with useQuery you pass a server action to the queryFn, the query will be called automatically when the component renders just like any query.
For me there’s no reason to use such a big library like react-query just for data fetching, it has a lot more but for a simple fetch just use standard library. Dont overengineer and add a lot of complex to a simple fetch. btw, you could create your own hook (which you’ll write once and use it a Million times) and it may be more performant
yep its similar... server actions are simply auto-generated api routes, same as trpc. So in my opinion its just a less mature alternative. The only thing server actions have going for them is they are "native to the framework" and hence can do revalidateTag() and notify the client to do the router.refresh() equivalent automatically.
The problem is, that it‘s always a post-request. Isn‘t it better to use Hono/ElysiaJS in the API-route like you did in another video? I am trying ElysiaJS at the moment and the „eden treaty“ is amazing. You can use it in react-query and in react server components. This way you can use middleware and all other stuff, you are used to on api-servers. And it‘s easy to seperate them if needed.
What about server components, query inside metadata, HydrationBoundary and prefetch query, cache concerns between next/fetch and RQ? would be great if you could cover all fetching aspects :) All the best
woah thanks Josh for sharing this incredible technique for fetching data way easier than creating api routes, Im already tired of doing bunch of routes lol.
Would you still use Mutation if the data needs to be loaded on the pageLoad? As per my understanding, mutations are generally used for CRUD operation with server and not really for data fetching.
can i have someone opinion on my approach? like im using server actions for fetching data and in pages.tsx is server component which i use the server actions function, and im passing the data trough props to specific component inside page.tsx which all the components here is client side component. then rendering the data in this client side. is this a good approach? and with react-query could it run on server components?
Yes I do kinda the same. In page.tsx which is async I make a fetch request to retrieve data from db and then pass this data as props to a client component. For the second question I can't answer you because I use nextjs server actions and I'm happy with it for now.
Does this help with "protecting" an api key, so the user cannot just simply take it out of the network tab? If not, do you have any recommendations on how to implement client side actions like updating, deleting, etc. without exposing the token to the client?
all this is nice, but we just not using useMutation as it is supposed to be used. (we have to mutate with useMutation) why just dont pass server action (that in your case gets data) to queryFn? const query = useQuery({ queryKey: ['todos'], queryFn: __your_server_action_getting_data__ }) and one more thing, even though it works server actions are idiomaticaly used basicaly like a post request (mutate data) - from documentation (not to get data) god knows if it is ok use it in production for now
I found setting up TRPC a nightmare with inadequate documentation, so I’ve just been exporting/importing types all this while. But this is actually a killer combo - thank you so much!
Who said that you can know the type returned by react query? you can pass a generic argument and it will use that as the fetched resource type on the data prop.
This is excellent if you have project which is browser only, but if project get bigger, and mobile app is needed i think server actions might be problematic. Please correct me if im wrong.
If by query options you mean the data, loading and error states, it won’t work in app router as actions are to be defined on server and hooks on the client
Way less bloated and requires zero configuration. One drawback would be implementing a convenient integration with validation libraries such as Zod, but I think it would be easy if you make a higher order function that deals with any additional layers of security like validation and so on.
@@haiiry I think you might've just removed the last obstacle for replacing tRPC with Next Server Actions. ✨ Didn't know this library existed earlier than now. NOTE: I'm speaking theocratically of course, I'm still not sure if Server Actions with type-safety and Tanstack Query can actually replace tRPC. I haven't put this to the test yet.
@@ChichaGad yes, with none of the downsides like security issues, worse performance, better scaling... I swear the people who keep saying this didn't use PHP much ever, you guys just parrot what people say on Twitter. And for the record, I'm not a huge Next.js fan (although I use it for work)
Impressive, very nice. Let's see Paul Allen's data fetching pattern.
_Look at this sublte inclusion of type safety , the tasteful thickness of it._ *Oh my god!*
_It even has the loading and error states handled by react-query._
@@entropysquare9683 something wrong, man? you're sweating
@@joshtriedcodingleave bro him bro. He just a sad little junior dev who’s trying to get some attention. Just keep doing great work ❤
@@joshtriedcoding how long has your channel been up? It seems like you've just discovered react-query and talking about it like it's something incredible. It's silly and funny at the same time (I think that's what the guy was trying to say, it's called sarcasm)
Can somebody explain the Paul Allen thing
“mutate” isn’t intuitive because it wasn’t really meant for get requests it’s meant for creating and updating data.
exactly
useQuery is the hook for data fetching, useMutation is for... mutating.
Great point, but his example makeRequest function that he was replacing as a POST request, so the useMutation hook is what should be used instead of that. However yes, the terminology being used is confusing - for getting/fetching data, you would usually use a GET request, or if using react query, you might use the useQuery hook. That being said, there are cases where it's acceptable to use a POST request to fetch data.
react query has a hook called useQuery which is the one to use for fetching data. useMutate is supposed to be used only for mutating/changing data, ie create/edit/delete.
Exactly..… he should have used useQuery on the client and use the await prefetchQuery on the server component and wrap the component consuming the data in a hydration boundary
Hi Josh. My main problem with this approach is data consumption and download speed / execution time, which may or may not be a concern depending on where you operate. I'm currently working for a client in Zambia and Malawi which is known for their expensive data and lack of network availability, so everything counts. As a test, I made both server action and /api route return the same payload ({foo:"bar"}}, both using POST (a restriction of server actions) and there are the results:
- server actions
- 447B download size
- 84ms to respond
- /api/ route
- 192B download size
- 25ms to respond
As the request in server actions points to the route itself it's likely running much more code than the /api route which just returns some JSON.
That said 100% agree this is a much better DX with types flowing through and love to see new and creative approaches to current problems!
My new favorite way of fetching data is with infinite loading through a server action. 10x devs use POST requests to get data.
That's a problem
10x devs use 500 to denote successful request on api endpoint
Mutations are meant to be used for creating or altering data -- i.e to mutate it., not for fetching data. Fetching data should use useQuery. POST, PATCH, PUT requests should use useMutation.
instead of using react-query I would just implement a custom hook for the project that reduce redundancy and track request state.
You can make it typed for typescript easily with a generic function, like
usemutation for getting data? lol, what about in memory cache?
You can use this approach with useQuery as well 👍
@@TheBelafleck server actions do not run in parallel. They are always sequential, by design. Fetching data like this is a disaster.
Amazing! Thanks to this video I went from Apprentice Brick Layer to Senior-Seasoned Full-Stackoverflow-BackToFront-End Devengineer and ready for retirement.
😂😂😂
Its nice but our component will be client side , not server side and our react query is still big dependency to use in our components
Not sure why you're using a mutation when this looks like a query
Sometimes you want to perform a GET request when a user clicks a button for example. You can't really control when a useQuery runs unless you specify the enabled property
@@outis99 There are ways to do that from query (if i'm not mistaken).
useQuery exports a "refetch" function for that.
We can also invalidate the specific query key using queryClient (useQueryClient).
And there might be other ways.
I might not be right about this, but as far as i know, mutate are intended for post, put, etc.
If anyone has a deeper understanding about react-query, i'm here to learn :D
@@outis99 server actions are always POST requests
@@StabilDEV I guess what he means is that with useQuery the query performs when the component is mounted and if yout want to controll it yout need to pass the enabled property and use refetch but with useMutation you just need to use the mutate function.
@@josepazmino842 yes, but the reason hes using useMutation is not for this reason. Like Stabildev said, all server actions are post so you can't use useQuery.
server actions are not made for fetching data, for this case better use "server only", (it is not provided by default). Basically you can achieve the same using native fetch and built in loading, suspense, error boundary. The big difference is because you use a hook, you are not more purely on server side, this require directive "use client", but your approach is much cleaner.
Good points. So it's better to not use react--query with server actions, because such action can't be explicitly marked as "server only"
Unlike queries, mutations are typically used to create/update/delete data or perform server side-effects. For this purpose, TanStack Query exports a useMutation hook. That from react-query documentation
Hey Josh, I definitely like this approach but the NEXT team are saying "handle form submissions and data mutations" and i have seen around the internet to not to use for as "GET" use only as Mutation function and so, What are your thoughts on this. Is it really a thing to use only as a Mutation or we can do whatever inside it without worrying about these things?
I’ve tried using actions for getting data. Went back to using usual fetch. Reason?
Server actions are executed sequentially, they can not run in parallel. And any other user interaction will be blocked until action is done. This has a huge impact on performance😕
Also, POST requests don’t really have the caching benefits of GET requests
And there is no caching on server actions
Thanks guys. My doubt is cleared now. But is there any way to get type safety for this use case? (other than trpc)
honestly i dont follow closely what they say, i feel like this approach is awesome and its so productive
❤@@vasyaqwe2087
If you want to know the type when using useQuery or useMutation, you can just define the type on that like useQuery() then data must be Response | undefined type
so you dont need to use server action on that.
I am still not fond of writing back-end code with Next.js. I simply do not see it becoming manageable as the project grows in size and complexity. It seems to be more suitable for a small-scale project, such blogging, with minimal logic, where using a large-scale framework, such as .NET or Spring Boot, would indeed be an overkill.
Furthermore, I followed the official tutorial from Next.js' website and there they even wrote SQL code, an approach that reminded me of when I started learning how to code with PHP, and I would write SQL, PHP, and HTML all together. It was about 10 years ago or so.
A simple CRUD, tops.
If you can manage it in .NET you can manage it in Next.js. Structuring a project has nothing to do with the language or framework.
Hmm why tanstack query isn't typesafe (btw why use useMutation for plain fetching?) ?
You can specify types for response where you set up your API handlers/
query functions (and by sharing type declaration across front and beckend you can get typesafety if you wnat/need across both project even if they are separate)
I think it's meant to be a post request but getUser is a bad example for that.
Also like you said, you could just specify the data type returned by the fetch request as a typescript interface, so this seems like he's demonstrating a benefit that isn't actually a benefit unless he's assuming we are working with JavaScript and not TypeSrcipt I guess
I don’t know. With my implementations I make my mutations typesafe without server action. Just react query
But then you have to create your own types when the code is already giving you the types. This method gets the types from the code/libraries. However the downside of this method, like you mentioned, is it uses only post requests(server actions are only post req) which don't cache. If you want 'type safety' either use trpc, server components, or validate with zod. This is mostly a dx issue anyways, your method works fine if done properly.
You can wrap ReactQuery hooks inside of your own custom hooks, then you can get type safety and any additional business logic, or statuses you need before returning to the page components. I will keeping using this pattern + api routes for now, still not seeing benefits from server actions, and it is a lot less intuitive to use.
so what about a server componet for fetching data ? same approach ?
I like the idea, but why would you use a mutation function to get data? Why not use the useQuery hook to get the data in that example? Apart from that the idea is very good!
+1, I use useQuery and pass a server action to it so we get the data on component render and not depend on user actions to fetch data.
@@fitimbytyci345 You're doing it right in this case, but don't forget mutations when the data will be created/updated/deleted with users actions, it's easier to implement optimistic updates with it.
What if you didn’t use use server directive in actions file that would still be the same no?
Anyone? What if getUser isnot a server action and is just normal function?
You can also add a type to the useMutation like useMutation
It seems like the reason this works in the video is because typescript can infer the types from the getUser function you defined. Still a nice pattern! Thanks for sharing!
I scrolled down the comments just to make sure someone mentioned this haha
Yeah but that would mean you have to maintain the types.
@@derkaouiabdelatif1524lol ditto
This is great, I’ve been using this.
Once you need to protect the mutations, schema validation or some kind of middleware, I’ve found trpc to be the best option. You can call trpc mutations in server actions.
If you’re not using react query, then next-safe-action is a good choice
I second this trpc api all the way. Schema validation is a pain writing manually and what's more important consistently.
Or just use next-safe-actions
What about error handling with useMutation? Server actions only returns plain objects. You did not mention that?
you can throw errors on your own
@@anhai-d9z yeah I know I wrote a simple actionWrapper function that throws for mutation, but I just wonder how other people do that 😃
I'm seeing that others are having issues with this in the comments - I would like to see your feedback. Thanks
what about server component?
I guess the only "drawback" is that it only works in client components, since it's a hook. But still a pretty great solution, I absolutely love react query!
Is that really a drawback? You can just run fetch directly in a server component
@@redeemr that's why I put it on quotes xD
@@redeemr does this mean you must maintain the same tags on the Tanstack Query side and Server Actions? How does this look in practice, to minimize the need to manage 2 caches?
@@teeldinho471 Pretty sure you have to manage 2 caches
@@teeldinho471 Well, you could just not use Next.js cache, passing "no-store" to your fetchs or using some lib that doesn't depend on fetch like Axios to make requests.
haha:
function useTypeSafeActionState(serverAction: T, initialState: U): [state: ReturnType | U, formAction: something] {
return useActionState(serverAction, initialState)
}
Typesafe now within 3 lines.
This approach is not good, because POST requests will not get cached by react-query, nextjs or anything. It's just a new request everytime
I mean that's by design, POST request shouldn't be used to GET a resource which I would expect to be cached
Edit: saw the other comments and understood what you meant, yep bad approach
@Josh, have you tried this with Prisma. Prisma doesn't allow fetching on client, and if you mark action as 'use server' then type safety is gone.
What is the benefit of using server actions for fetching instead of TRPC?
i don't see any also
Good question
@@FIash911 how you deal with optimistic updates using trpc? Nowadays we have it built in in react, but I does't work well if trpc.
what benefit does "use server" directive have in getUser function? what if instead of making it a server action we made it a normal function without "use server" directive?
What about the loading state? What about the error state? I can't relate to these problems cause I use Svelte 😊
Do you typically separate out your server actions into separate files or just include them all in an "actions.ts" file? I'm curious how you prefer to structure your files/folders in general, I'd love to see a video on that at some point!
interested
Also interested. Currently I have my actions in /server/actions with each being grouped somehow if possible. Grouped based on table names or something. But I've seen one file and I've seen a single actions.ts in the same directory as the page using that action
I have a problem, if you want to handle errors, in Server action directly throw errors in development mode can, But in production mode the error message will be hidden, how to solve?
Same issue, did you find a solution ?
error.tsx
If you don't need caching or invalidation you can even invoke the server action within a custom handler without using RTK mutations, but you have to set a custom loading state, which kinda sucks tho. Also there's some weird errors that occur on the form html element when using server actions directly on them, which is really annoying. So yeah. Invoking actions inside handlers/useEffect or simply react query is much more preferable.
This looks great! However, doesn't react query provide support for typescript using generic types? I personally love extracting every useState and useMutation with fetching logic into separate hook, which take as a parameter the query options object (which also has special type provided by react query), therefore making those hooks highly reusable across many different components due to their customizability.
Tan stack query hooks actually do a pretty good job inferring types, in some special cases you might need to pass generic parameters for type safety, but you can definitely use them without the server action combination.
Pls someone tell me the right way to fetch data in server components. I currently fetch directly from my db on the server side but I noticed there’s no caching.
I think that server actions are called sequentially and not in parallel by Next (since that is considered to be most appropriate for mutations). So, this pattern might introduce really bad client-server waterfalls and lead to poor performance.
Legit been doing this for time, I'm glad this got Josh's cosign ;)
could it possibly replace the trpc as a whole? this combination of server actions and react query?
Possible. Especially if used in combination with cookies for authentication so you can fetch the current session anywhere on the server. But also im realizing that server actions are executing sequentially and not in parallel. What do you think?
Didn't know react query works with server actions, that's great!
Only downside is, server actions are always POST, which doesn't make much sense. I mean, you can get data on the server, but if you're using react query and want to have any sort of dynamic loading going on, you'll still need GET endpoints for actual queries.
I mean, maybe not *need*, but I refuse to ever fetch data with POST.
I'd honestly stick to the default verbose server actions (maybe wrapped behind a custom hook) if only they stopped using FormData. That api has been growing on me, but I really don't want FormData.
While not sure about react query, RTK query does give the ability to add types for both response types and query args with all the isLoading, error, etc states
Yes, React Query also has that ability, but inference is just better
what you are talking about is native with Nuxt, data fetching, fully typesafe
But what about use the same backend for mobile apps?
it seems very simple compared to tRPC but are there any disadvantages
I was using this moethod in my project but it was not working in vercel. So, switched back to api routes
Combination of Tanstack/react-query and next js server action would make my life so much easier.
I fucking love you, been stuck with fetching api because of cors or wtf that was and the route method was not working, decided to sleep, after 4 hours and BAM in the morning watched your vid and it worked, ty,
Is the actions.js file a good place to have functions that call APIs?
This approach makes sense with mutations, but how would this work with fetching a query?
afaik 'data' in useMutation works differently, it is "the last successfully resolved data for the mutation", and since it doesn't make sense to call 'mutate' on a query, how do you get the data?
I would love to have a similar approach for simple GETs, that doesn't involve using server components and giving up on react-query and its loading state management
It works the same, with useQuery you pass a server action to the queryFn, the query will be called automatically when the component renders just like any query.
I like this approach but I have a feeling the default method of a server action being POST can cause issues somewhere.
For me there’s no reason to use such a big library like react-query just for data fetching, it has a lot more but for a simple fetch just use standard library. Dont overengineer and add a lot of complex to a simple fetch.
btw, you could create your own hook (which you’ll write once and use it a Million times) and it may be more performant
Nice one. Question: In comparison, how do you feel about the t3-stack, or TRPC in general? Sounds like a very similar approach.
yep its similar... server actions are simply auto-generated api routes, same as trpc. So in my opinion its just a less mature alternative. The only thing server actions have going for them is they are "native to the framework" and hence can do revalidateTag() and notify the client to do the router.refresh() equivalent automatically.
server actions theoretically eliminate the need for TRPC. But TRPC gives you more than just type safe requests.
What do you think about react-query in combination with hono? Maybe not so simple like server actions but much more cleaner and also type-safe.
How would you use this pattern for external APIs?
what if i have a nestjs server ? it will not work... again I have to give types on server actions
Why do you need server actions?
We've been using this pattern without server actions for a long time. I can share our project structure if you're interested
Amazing! Is possible to protect the server action with authentication? For eg. Create task action cannot be used before you logged in
Yes of course. You have access to cookie in server, and you can get token and check it in server. But I use nextauth
The problem is, that it‘s always a post-request. Isn‘t it better to use Hono/ElysiaJS in the API-route like you did in another video? I am trying ElysiaJS at the moment and the „eden treaty“ is amazing. You can use it in react-query and in react server components. This way you can use middleware and all other stuff, you are used to on api-servers. And it‘s easy to seperate them if needed.
What about server components, query inside metadata, HydrationBoundary and prefetch query, cache concerns between next/fetch and RQ? would be great if you could cover all fetching aspects :) All the best
woah thanks Josh for sharing this incredible technique for fetching data way easier than creating api routes, Im already tired of doing bunch of routes lol.
use zod for validation and type safety?
Would you still use Mutation if the data needs to be loaded on the pageLoad? As per my understanding, mutations are generally used for CRUD operation with server and not really for data fetching.
is great for accomplished your API code with your Presentation code - like a junior dev
Do you think it's a good idea to call an external API from from the server action?
fascinating! awesome! thank you very much indeed, Josh
This is really cool Josh! Thanks for sharing ;).
I am old school developer. I just put Mvc everywhere it works everywhere. For everything.
is this working if we disable JS?
i thought the benefit of server actions is to be able still to mutate even if user does not run JS
Basic react query with Redux. There is such a close connection in syntax.
can i have someone opinion on my approach?
like im using server actions for fetching data and in pages.tsx is server component which i use the server actions function, and im passing the data trough props to specific component inside page.tsx which all the components here is client side component. then rendering the data in this client side.
is this a good approach?
and with react-query could it run on server components?
Yes I do kinda the same. In page.tsx which is async I make a fetch request to retrieve data from db and then pass this data as props to a client component. For the second question I can't answer you because I use nextjs server actions and I'm happy with it for now.
Does this help with "protecting" an api key, so the user cannot just simply take it out of the network tab? If not, do you have any recommendations on how to implement client side actions like updating, deleting, etc. without exposing the token to the client?
Why useMutation instead of useQuery if you're just... querying for data?
all this is nice, but we just not using useMutation as it is supposed to be used. (we have to mutate with useMutation)
why just dont pass server action (that in your case gets data) to queryFn?
const query = useQuery({ queryKey: ['todos'], queryFn: __your_server_action_getting_data__ })
and one more thing, even though it works server actions are idiomaticaly used basicaly like a post request (mutate data) - from documentation (not to get data)
god knows if it is ok use it in production for now
well, it looks ok, but what about doing like POST or PUT. Is there a generic solution for all types of requests?
Wouldn't this be a fair bit slower than fetching in a server component?
Does it have any effect on caching responses?
amazing content. can you please show how to use this in a pure react full stack app ?
I found setting up TRPC a nightmare with inadequate documentation, so I’ve just been exporting/importing types all this while. But this is actually a killer combo - thank you so much!
same dude!! tRPC is such a nice tool but the setup has been so unintuitive for me too. appreciate ya
It takes like 2 mins or less to setup trpc
Use T3 stack.
I think Upstash are lucky to have you in their team.. Amazing tutorial Josh 🎉
Nuxt 3 has it all built-in, way less complex great typesafe DX
BuT ReAcT more jobs !!!
Who said that you can know the type returned by react query? you can pass a generic argument and it will use that as the fetched resource type on the data prop.
what about seo?🤔
Aren’t onSuccess and onError being/are deprecated?
deprecated only for useQuery
@@mamlzy Ahhh, thank you for the heads up.
I was the doing the same, its really a good pattern for fetching data.
Any benefit over trpc?
This is excellent if you have project which is browser only, but if project get bigger, and mobile app is needed i think server actions might be problematic. Please correct me if im wrong.
Pairing this with initialData sounds OP. And also exporting the queryOptions from the action itself.
If by query options you mean the data, loading and error states, it won’t work in app router as actions are to be defined on server and hooks on the client
Title should be changed to "Mutating Data Doesn't Get Better Than This"
can mutation data get cached?
Wow pretty soon next.js will be able to do things I could do 15 years ago in asp web forms amazing.
What about tRPC? instead of this approach? - Any pro or cons?
trpc has enourmous setup to it, this is straight forward super easy
Your energy is top-notch 😅😅
The best data fetching method in Nextjs! Thanks!
create a josh stack please, a community driven open-source
Can you create a website or application to book airline tickets 🙏 🙏🙏that would be so helpful
Isn't this just like trpc?
Way less bloated and requires zero configuration.
One drawback would be implementing a convenient integration with validation libraries such as Zod, but I think it would be easy if you make a higher order function that deals with any additional layers of security like validation and so on.
@@glowing_flare So like next-safe-action?
@@haiiry I think you might've just removed the last obstacle for replacing tRPC with Next Server Actions. ✨
Didn't know this library existed earlier than now.
NOTE: I'm speaking theocratically of course, I'm still not sure if Server Actions with type-safety and Tanstack Query can actually replace tRPC. I haven't put this to the test yet.
@@ChichaGad yes, with none of the downsides like security issues, worse performance, better scaling...
I swear the people who keep saying this didn't use PHP much ever, you guys just parrot what people say on Twitter. And for the record, I'm not a huge Next.js fan (although I use it for work)
i am think i am only using like combination of tankstack and servertion but no. Now i am confident bro thanks