thomasballinger
commented
3 days ago This issue describes a higher-level interface that Convex Auth currently presents with the Password provider.
The approach to getting (at least some of) these errors that matches how Convex Auth works today would be to
- pass a custom callback into the Password provider. Currently the only callback accepted is
validatePasswordRequirements - throw a ConvexError in this function
- catch the ConvexError on the frontend
See this example of exposing an error to the client: https://github.com/get-convex/convex-auth/commit/c95f02700207a7679189ad3fbb1765512e085615#diff-119a75ca9b2e59f861bfed91083e096f122bb8084899dc4b0d8804d26eea2572L52
So for some of these, we'd need a new callback like validatePassword that allowed you to customize this logic and throw whichever errors you wanted.
That said, this higher level interface is really sensible. It could be a new provider or it could be a common configuration of the existing Password provider.
I think we should have two issues here, one for presenting data like you want and a shorter-term idea for providing the specific errors you'd like. Which of these errors are important to you?
xixixao
There are a couple of posts on the discord about this but doesn't seem to be any answer. In short, it's really unclear how to properly handle expected (application) errors. These types of errors are really common in auth and being able to precisely handle them in the frontend - like with our own custom error messages - is really important.
In an ideal world I think that all expected errors should be return by a sum type (like an
EitherorResulttype) so we can cleanly pattern match on them. If that's outside of convention, even just having a standard error type (likeConvexError) with a clear enum of error codes to handle would be great.I'll add what firebase uses for reference here. All of these you can cleanly pattern match after calling firebase
signUpetc