skip to Main Content

I understand the use of server actions in client components, for form submission for example or any other mutation.

As for data fetching, in server component we can directly access the db so that’s great. And in client components it’s a bit more tricky but there are still great solutions, the one I’m using is the trpc + ReactQuery combo.

However I often see people using server actions inside server components, And I cant figure this one out, because we can directly access the db as mention before.
So why not just create a simple function call that does that mutation. Why use server actions in server components?

Maybe I’m missing something, but I couldn’t find any good reason to do so.

I tried both ways and there seems to be no significant difference in performance or any other metric that I could think of.

2

Answers


  1. However I often see people using server actions inside server components, And I cant figure this one out, because we can directly access the db

    Yeah, if that’s all they’re doing then they’re doing it wrong. The reason you would want to do that is that unlike regular functions server actions can be serialized across the client/server boundary and called from client components:

    function SomeServerComponent() {
      async function updateDB(somevalue) {
        await dbClient.update('someKey', someValue);
      }
    
      return <ClientOnlyComponent onUpdate={updateDB} />;
    }
    

    Here were passing the server action function as a prop to the client-only component, the client can just call it normally and the build process/runtime handles the serialization logic across the client/server gap without actually exposing the db interface to the client.

    Login or Signup to reply.
    • you can create a server Form component, and submit it with actions. your form component will be server compoennt so it will benefit from being a server component. from docs

    Server Components support progressive enhancement by default, meaning
    the form will be submitted even if JavaScript hasn’t loaded yet or is
    disabled.

    So server actions can execute even in scenarios where JavaScript is disabled within the browser.

    • server actions are just functions so they are reusable. you can use the same action from client and server.

    • from the same docs above:

    Server Actions integrate with the Next.js caching and revalidation
    architecture. When an action is invoked, Next.js can return both the
    updated UI and new data in a single server roundtrip.

    • actions have isPending state status. if user is sending a mutation, you can show the state of the mutation while user is waiting. you could wrap the server component with Suspense component and show the fallback but this is very expensive operation. Suspense fallback replaces the entire component tree inside the boundary with a single fallback, which can be great for full-page or section-level loading. if your component does mutation or fetching multiple times this will be very expensive for your application. isPending lets you handle loading at a more granular level. For example, you could disable a button or show a small loading spinner next to the button without wrapping the entire component in Suspense.
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search