Confusion around control flow

[justin-hackin]

I'm having a hard time understanding how to deal with basic control flow from the documentation here. The FormStrategy example doesn't not handle any "unhappy" paths. It's not clear what it means to throw an error inside the FormStrategy constructor parameter in the usage section.

The tutorial here suggests that there's a some kind of magical subclass of Error, AuthorizationError, that if thrown in the form strategy would cause the isAuthenticated to resolve an ordinary Error based on Authenticator<User | Error | null>. Given that this AuthorizationError is only mentioned in the context of performing the authenticate in the docs, if that's the case, it seems like a rather unintuitive behaviour that is undocumented. Where the null in that generic comes from is still a mystery to me because the form strategy never returns null. Is there a condition where the library causes a null return?

What's even more confusing to me is that if I have a failureRedirect in the isAuthenticated method options, then it would seem that all the code below the isAuthenticated is unreachable in the error case and then the developer must put unnecessary type guards to tell TS that the resolved value for isAuthenticated is a User and not an Error before fetching user-related data. Is it not possible to have this method thow the error for a more sensible code flow where our loader handles the redirects on the catch of an error?

[justin-hackin]

I think maybe the tutorial I mentioned is just misleading. I see another example here which throws errors but only has a User type of return. Sadly, the other tutorial was at the top of my search results and it had no comments.

[sergiodxa]

The Remix Auth docs has a section on error handling, I don't endorse any tutorial outside official documentation, answers here in the repo or content on my own blog.