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.

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.

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