Post

A @tanstack.com start design question ( @tannerlinsley.com @tkdodo.eu ) Why do you have to THROW a redirect instead of (early) returning it? tanstack.com/start/latest... Throw is commonly supposed to handle an erroneous situation. Redirect doesn't seem like one. TIA for response!

tanstack.comServer Functions | TanStack Start React DocsWhat are Server Functions? Server functions allow you to specify logic that can be invoked almost anywhere (even the client), but run only on the server. In fact, they are not so different from an API...

0 reposts6 likes

Well for one it doesn't mess with the types. So you can return some data from the server function and if you want to, throw the user to login but the types will only show the data your returning.

I understand I "can" do lots of things within a specific API design. But redirect seems a really normal result. Throwing is commonly used for abnormal interruption. Not to mention that SE in general is slightly moving away from exceptions, mostly, due to overhead due to building stack traces.

You could achieve exactly the same scenario as you described with many different APIs. The fact that you "can" do that, kind of, brings nothing, as it's not exclusive for this API.

"Well for one it doesn't mess with the types." Do you mean that server functions can ignore returning the redirect? If so, IMO that's not a good thing, as it'll bring more confusion. Looking at a limited return type you won't expect a behavior that's baked in by design. Explicit > Implicit.

I mean redirects are as normal as throwing errors. I don't see the problem with not returning them. I have very rarely had an endpoint that would redirect, but your mileage may vary. And I don't think you're going to feel the perf impact of throwing instead of returning 😅

> And I don't think you're going to feel the perf impact of throwing instead of returning 😅 If you have no users (or close to), you're right. You're on the server, not the client.