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.

"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