refactor(provider): return results from every useAuth helper#99
Merged
Conversation
Bccorb
force-pushed
the
refactor/provider-result-convention
branch
from
July 20, 2026 15:05
786a1ca to
b2c7f74
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Unify
useAuth()on the same result convention as the headless client. Every provider helper returnsSeamlessAuthResultand none of them throw.Closes #92.
The problem was bigger than the issue described
#92 framed this as one split: client returns results, provider throws. Taking inventory showed
useAuth()alone had four styles side by side:deleteUser,updateCredential,deleteCredential,switchOrganization,listOAuthProviders,startOAuthLogin,finishOAuthLoginlogin,verifyStepUpWithPasskey,verifyStepUpWithPasskeyPrf,verifyStepUpWithTotphandlePasskeyLoginrefreshStepUpStatusSo there was no rule to learn, only per-method memorization, and #64 would have propagated that to every adapter.
Three silent breakages this could have shipped
The conversion compiles cleanly whether or not callers are updated, because a result object is always truthy. That makes the failure mode silent, and three call sites were affected:
Login:if (passkeyResult)was always true, so a failed passkey login would have navigated home as if it succeededPassKeyLogin: same shape, same outcomeOAuthCallback: used.then()/.catch(), and since the helper no longer rejects,.then()ran on failure too and navigated homeAll three now check
error. Worth flagging because typecheck cannot catch this class, so any adopter doing the same migration should grep their own truthiness checks rather than trusting the compiler.State updates still gated on success
Helpers that mutate provider state apply the change only when the call succeeds.
switchOrganizationstill refreshes the session,deleteCredentialstill prunes local state, andlogoutkeeps itsfinallyso local state clears even on a failed sign-out.Changes
src/AuthProvider.tsx: every helper returns a result;AuthContextTypeupdatedsrc/views/{Login,PassKeyLogin,OAuthCallback}.tsxandsrc/components/OAuthProviderButtons.tsx: consume resultsuseAuth()signature block and credential example are updatedChecks
npm run typecheck,npm run lint,npm run format:checkclean