React + Servers = Confusion

I am playing around with app router and all of its things for a while now, and it seems pretty magical. In a positive and a negative way.
If you understand how everything is intended to be used, you can really fly doing things.
But things are getting so implicit and are losing the self-explaining part that e.g. page router has, that it's hard to keep up to date, and master the thing.
I'm not even starting on how it must be like if you are working in a bigger team with engineers that are not as passionate as most of us are.

Maybe I wasn't paying too much attention, but before watching this video I did not know what server actions are, and I still do not understand anything about them.

Your simplest vanilla example still somehow imports from `db`, `trpc`, `next/cache`, and `drizzle` and I don't know what any of these are!
Don't know about `db` because it's part of the repo you're showing so I did not see it before, the others - never heard of them. How could that be a simple example?

And then it becomes worse. React-query, Data Access Layer, `caller` pattern, "use server", "use-server" but it's in a file, not in a function...

what about import server actions into a server component to act like a post route?

So react server is a less efficient version of what qwik is doing. I’m just gonna continue to avoid react like it’s the black plague.

This isn’t React. This is Next nonsense.

wtf was that? at this point i'd rather use php

I totally appreciate the work you do to make these concepts clearer for all, but
The mess called js frameworks we're pushing is just absurd. This is discouraging beginners to get into web dev. Because of the millions of things we are pushing to be in this space, the moment you go back to edit a nextjs app you build last year November, you start seeing crazy errors and package updates with api changes and no other dev can make changes.

Are you getting paid? Because at this point - There's no point to make.

I am currently using the trpc client approach and I am having problems with refreshing page content. Could you do something on Next caching? I feel like there is no good way to invalidate a specific page other than the one you are currently on with the trpc client approach. For example imagine a page /editContent where an admin can edit a database entry which is displayed at /content. How would I inform the client, that its cache for /content is invalid? I would need to invalidate the cache for every client currently storing the old content of /content.

The first one smells like webforms...

Well, server actions looks good only if you plan to use your api on your nextjs project and nowhere else. The day another team will request you an access to an endpoint of your company from their tools, you will have to write a new backend for them lol

I dont get why would anyone need trpc anymore? Even zod on backend? Server actions once exported from a file marked "use server" are fully typesafe and usable on both client and server components, its truly write once and use everywhere, couldn't be more simple. I integrated them with tanstack react query on client components and used it's methods for optimistic updates/revalidating data, passing the action as the fetch function.

Am I missing something?

Nice options, I want to check more deep about that. I liked it, thanks :)

Just a few notes base on my recent dive into server actions. All data going into your server action doesn't have to be included in the form itself. You can pass in additional args through bind (e.g. <form action={myAction.bind(null, ...additionalArgs)}>. Also, and this is a bit of an ugly hack, you can force React to clear your form fields on revalidation by changing their keys. I do it by setting their key to performance.now() (e.g. <input type="text" key={performance.now()} />). No need to create a client component just for that. Additionally, I suggest you use redirect("/path") instead of revalidatePath("/path") at the end of your server actions because, when running with JS disabled, refreshing the page after submitting a form will cause it to submit again (old school webdev problems frfr).

please please explain concurrent react!!!!!!!!!!!!!

that use server string literal still is the most disgusting thing i have seen

I just use telefunc and no issues at all, this also comes at a benfits of getting rid of nextjs, trpc, tanstack query, etc that slow down everthing. Basically I use one that remove 3-4 other dependencies.

Server actions in a different file is what I did with the experimental flag and what I continued doing after upgrading my project. I really don't like mixing my client & server code.
Something really cool with that is that you can still share definitions between client & server while at the same time maintening a good old separation of concern.

So trpc will just become a simple api for using zod on inputs and outputs.
Nobody with react will ever use trpc as a client anymore, its just easier to call the server trpc method itself and a export this pretty async function using server actions.

Is that just next js or is that react implementation?

Because it would be very nice to have this "action" endpoint that has many action types automatically created easily outside of next.

By biggest fear is react just becoming next.

React has jumped the shark.

Really helpful video and I really like the last one!
I'm new to app router and I'm currently doing `Object.fromEntries(formData.entries())` for my server actions then parsing it with a zod schema of my expected shape. Any drawbacks to doing this?

This shit was the last straw before I quit Javascript. I converted from fullstack JS engineer to non-JS backend engineer and I'm never touching JS again unless I'm the one making the decisions. I'm getting too old to deal with the hyperactive JS monkeys "innovating" just because.

Switching to Astro, Nexting next. Don't like where it's going, Very bad design choices.

I strongly dislike everything I've seen about server actions. They don't solve a problem that I have.

I'd love to see an example where going all-in on server actions makes sense, especially for teams with non-trivial codebases.

As I have a separate backend I won't be moving off tRPC anytime soon but even if I didn't, I have to say I still much prefer tRPC over the way they showed server actions directly in components, I like the client server separation. Throw in middleware, context and the other useful features that tRPC provides and I think it clearly offers a better DX than server actions do.
Big fan of server components but server actions, not so much

awesome, thanks
we started using server actions just this week at my workplace

this is content

I would call the server action directive "use another footgun". React is certainly pushing the community forward, but it relies on weak abstraction foundations like VDOM and useEffect and instead of working on those they keep on adding more stuff that is fragile and hard to make good. Looks like it is time to switch to Solid.js, it can also have server actions in future, after learning on react mistakes

Was hoping to see a link to that taint video in the description 😪

all I see is an inferior meteor.js

There is one thing to mention when it comes to "use server". It doesn't just have different behaviour depending on where you use "use server", also it has different behaviour depending on where you use the function itself.

If you drop it into a useFormStatus it will prepend an extra argument. I think thats where the most amount of confusion lies. They're changing the order of arguments making a function much less reusable than it could be.

Additionally, error handling has also confused users as `redirect` throws the error as an instruction to next to redirect. Blew my mind once I put that thing in a try catch wondering why nothing worked.

Super helpful video - thanks Theo! Sometimes, because of all the ways our minds have changed with TRPC, using createCaller still feels a little wrong, but this video helps justify it and the fact that I need to spend time doing the mental model shift.

I would like to see how we can write tests for this.

Ok, the subscribe thing got me there hahahah

Thanks Theo, great content as always! A video on Phoenix/Elixir Theo :)

Thank you Theo for mentioning next-safe-action!

So… it only took us twenty years to recreate Apache Struts?

Javascript is a mess, we need a replacement for the web.

I have been using react for two years
I used redux, redux-toolkit, react query etc

But I didn’t used trpc because you could have to consume a backend different than NodeJs with typescript and it’s enough to use react query

Also I found “use-server” very confusing and not completely necessary, because we have easier to understand alternatives to do this.

The main advantage of using use-server is saving some lines of code and declaring types.
But do you think it is worth it to confuse an entire community for this purpose?

When you code not only T3 will read your code and will understand it, but other people will have to do it.

And trust me, is better to put things clear to other people.

next-safe-actions package is the goat

I am using clerk to create a auth object in the middleware, since we currently need to use „createFetchHandler“ I need to use getAuth(req) for that therefore need the request in the createContext function.
Anybody got this issue solved?
Or do we need to wait for a version bumb 👀

I don't see the difference in the 4th action, you are basically using the "use-server" function in a different file. I've been using this for months as well. I don't want my server functions in the same file as the component

Enjoyed the video, as usual. Not suuuuper into the aggressive "look at all this value I'm giving you, subscribe or you suck" bit. I'm subscribed, just find it very off-putting

All these new updates have highlighted all the benefits of using something else.

sveltekit has server actions with much more simpler approach no headaches

Very helpfull, thank you!!!