Also did some research on this it on next docs but nothing comes..

Okay answer is this, you need to create separate file for it and then import it. in our case create.ts

Yeah this is kinda interesting, because the docs say you shouldn't do exactly what you're doing here and should instead wrap the action in startTransition for custom invocations. So I wonder how we're supposed to receive repsonses from our actions on the client since that hook doesn't return anything.

I saw another dicussion about this and people were saying that useTransition is useless/not needed for server actions, others saying it's needed to prevent showing loading.js file while the action executes, idk it's a bit of a grey area that I'd like improved on within the documentation, but, for now I'll just follow what the docs say and wrap in startTransition

Its really interesting indeed, I dig a lot in this and there is no answer for it yet.. server actions are great itself, but its useless if u can't return anything to client

Yeah I guess in this area, Route Handlers will need to be used, but, yeah I agree, feel like something is missing with server actions in the documentation since it's not showing any examples of server actions returning anything to the client.

useFormState is the only example that shows something like this.

which is in experiemental yet...

Had a similar question here: https://discord.com/channels/752553802359505017/1007476603422527558/threads/1167194630698307594

calling the server action directly is not clear, I needed that to be able to call "mutate" on SWR too (instead of using the server data, I use them to initialize SWR cache for polling, this pattern is also common when using sockets for real-time)

useFormState is indeed a way to get the return value, in a "hookish" way

but that's mostly for rendering, in event listener I think you are right you should get the value as a return value

which seems possible but only vaguely documented at this point

I think your current code works but the action is not "interruptible" if the component stops being displayed, or smth like that, transitions are really hard to figure...

Yeah it's supposed to prevent blocking more important state updates, I saw that server actions use useReducer under the hood so there is some state syncing happening that probably needs to happen transitionally. I'm not entirely sure, but, I hope the documentation around the custom invocations gets better/more descriptive.

ok that would make sense indeed

"use server";
export const getAllProducts = async () => {
  try {
    const products = await prisma.item.findMany();
    return products;
  } catch (e) {
    console.log(e);
    return null;
  } finally {
    await prisma.$disconnect();
  }
};

Here is little code snippet from my small project. Hope it helps. I use return object and in client I handle it like this :

import { getAllProducts } from "@/actions/product.action";

  const [products, setProducts] = useState<Product[] | null>();
  const [query, setQuery] = useState("");

  // Fetch data and store in products
  useEffect(() => {
    getAllProducts().then((p) => setProducts(p));
  }, []);

When I am working with forms I implement like this

      <form
        ref={formRef}
        action={async (formData) => {
          const { message, success } = await addProduct(formData);
          toast({
            title: message,
            variant: success ? "success" : "destructive",
          });
          if (success) {
            formRef.current?.reset();
          }
        }}
      >

And in server

export const addProduct = async (formdata: FormData) => {
  const prisma = new PrismaClient();

  const product_name = formdata.get("product_name");
  const stock = formdata.get("stock");

  if (!product_name) {
    return { success: false, message: "Product name is required." };
  }

  try {
    const data = {
      item_name: product_name as string,
      stock: stock ? Number(stock as string) : 0,
    };

    const product = await prisma.item.create({
      data: data,
    });
    revalidatePath("/products");
    return { success: true, message: "Product added successfully." };
  } catch (err) {
    console.log(err);
    return { success: false, message: "Error adding the product." };
  }
};

yeah so you don't bother much about transitions

most code I've seen in the wild do not use them in the end

Yeah that approach is similar to mine, its a nice approach considering that there is no appropiate docs for it