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!

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.

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 think I was using Remix a few years ago and I returned a redirect and some data. Now in the code I had to check if the response was a redirect, but the way redirects work your code in the frontend for that redirect won't run because the redirect has interrupted it and moves the flow to another url

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 😅

Redirect is not an error. Nothing to add from my side...

Yeah, it's not an error. I said the flow is similar. And I'm OK with the semantics being a bit wrong. So I guess let's agree to disagree 😁