Fetching Data Doesn't Get Better Than This 

“mutate” isn’t intuitive because it wasn’t really meant for get requests it’s meant for creating and updating data.

Impressive, very nice. Let's see Paul Allen's data fetching pattern.

Not sure why you're using a mutation when this looks like a query

My new favorite way of fetching data is with infinite loading through a server action. 10x devs use POST requests to get data.

Amazing! Thanks to this video I went from Apprentice Brick Layer to Senior-Seasoned Full-Stackoverflow-BackToFront-End Devengineer and ready for retirement.

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!

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.

Combination of Tanstack/react-query and next js server action would make my life so much easier.

usemutation for getting data? lol, what about in memory cache?

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 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.

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

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!

This is really cool Josh! Thanks for sharing ;).

Legit been doing this for time, I'm glad this got Josh's cosign ;)

Amazing! Is possible to protect the server action with authentication? For eg. Create task action cannot be used before you logged in

Nice one. Question: In comparison, how do you feel about the t3-stack, or TRPC in general? Sounds like a very similar approach.

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.

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.

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.

Yep, I didnot used server actions with react query. I have one question, should i still use next-safe-actions thats another library, will be sever actions safe if i wont use that library?

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.

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!

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?

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

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

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?

Well and very well explained, thanks so much

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!

This is useful for me! Thanks Josh

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?

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

I think Upstash are lucky to have you in their team.. Amazing tutorial Josh 🎉

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?

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

been using this for a while too it's pretty cool

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!

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.

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.

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.

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?

Wow new learning from you thanks ❤❤

Mind blowing 🤯 I can't believe josh how you you teaching and also how you making awesome videos such like this video awesome ❤

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.

The best data fetching method in Nextjs! Thanks!

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.

This is amazing, Thanks for sharing...

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)

could it possibly replace the trpc as a whole? this combination of server actions and react query?

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?

I am old school developer. I just put Mvc everywhere it works everywhere. For everything.

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

How would you use this pattern for external APIs?

What about error handling with useMutation? Server actions only returns plain objects. You did not mention that?

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.

haha: function useTypeSafeActionState(serverAction: T, initialState: U): [state: ReturnType | U, formAction: something] { return useActionState(serverAction, initialState) } Typesafe now within 3 lines.

We've been using this pattern without server actions for a long time. I can share our project structure if you're interested

Pairing this with initialData sounds OP. And also exporting the queryOptions from the action itself.

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.

Your energy is top-notch 😅😅

Does it have any effect on caching responses?

I like this approach but I have a feeling the default method of a server action being POST can cause issues somewhere.

What if you didn’t use use server directive in actions file that would still be the same no?

I have been using it for quite some time and here is video about it )

I'm seeing that others are having issues with this in the comments - I would like to see your feedback. Thanks

What is the benefit of using server actions for fetching instead of TRPC?

😮 smooooth 😂 I love the workflow

Basic react query with Redux. There is such a close connection in syntax.

what if i have a nestjs server ? it will not work... again I have to give types on server actions

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.

use zod for validation and type safety?

Thanks for nice tips

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

Title should be changed to "Mutating Data Doesn't Get Better Than This"

Wow pretty soon next.js will be able to do things I could do 15 years ago in asp web forms amazing.

Wow! I think this has the potential to eliminate the need for tRPC. That means zero configuration for Front and Back type-safety, and less bloated full-stack projects. It's amazing to say the least! 🔥

I was using this moethod in my project but it was not working in vercel. So, switched back to api routes

create a josh stack please, a community driven open-source

Thanks for the tip 👍

But what about use the same backend for mobile apps?

amazing content. can you please show how to use this in a pure react full stack app ?

Josh👌 Very Helpful

Congratulations, you just reinvented tRPC

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

Any benefit over trpc?

i use next built in swr. it does the job

I like the server prefix.

God bless you! Very clean solution LOL

I was the doing the same, its really a good pattern for fetching data.

Nuxt 3 has it all built-in, way less complex great typesafe DX

What about the loading state? What about the error state? I can't relate to these problems cause I use Svelte 😊

looks great and similar to the idea used in t3-app actually.

I basically do this but with TRPC actions because I like to make all my DB calls from a router still 😊

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.

Looks awesome

Dislike the naming conventions, mutate != GET requests. The destructuring renaming adds mental overload for no reason. Using API routes is still OG in enterprise level apps imo

SWR > react-query 😊

react-query is basically react-async :P