feat: adding delay after OTP code validation

[jcaleb4]

Pull Request Checklist

• Did you add new tests and confirm existing tests pass? (yarn test)
• Did you update relevant docs? (docs are found in the site folder, and guidelines for updating/adding docs can be found in the contribution guide)
• Do your commits follow the Conventional Commits standard?
• Does your PR title also follow the Conventional Commits standard?
• If you have a breaking change, is it correctly reflected in your commit message? (e.g. feat!: breaking change)
• Did you run lint (yarn lint:check) and fix any issues? (yarn lint:write)
• Did you follow the contribution guidelines?

Using the discord branch just to test other login methods working along:
https://www.loom.com/share/02f6b5b3928a4b6a9a543aeb96d21ab3?sid=fb440839-b3ce-4fe7-bee8-4e87bfeb0dd5

---

PR-Codex overview

This PR introduces the useAuthContext hook for managing authentication context in the application, updates the LoadingOtp component's delay, and enhances the AuthCardWrapper component to utilize the new hook for better user authentication handling.

Detailed summary

• Added useAuthContext export in index.ts.
• Introduced useAuthContext documentation in useAuthContext.mdx.
• Updated AUTH_DELAY from 3000ms to 1000ms in otp.tsx.
• Removed commented-out setAuthStep in LoadingOtp.
• Integrated useAuthContext in AuthCardWrapper for managing authentication state.
• Updated logic in RenderContent to show/hide the authentication card based on user and authStep.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
aa-sdk-site	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 27, 2025 7:08pm
aa-sdk-ui-demo	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 27, 2025 7:08pm

[graphite-app]

How to use the Graphite Merge Queue

Add the label graphite-merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[moldy530]

What's goin on here? This seems a bit of a smell for a couple reasons:

1. having a delay implies that there's some async state that we are waiting to be resolved (and 3 seconds seems high)
2. If this is something that should be happening for all users of the UI components, then having it live only in the ui-demo folder means that folks using the auth card in an embedded setting would have to do the same thing here which doesn't seem very intuitive.

I think I'm missing some context on what was happening before we introduced the delay, what's the intention behind this and the original change?

[moldy530]

Looking at this file a bit... seems like a few things are at play potentially.

If calling authenticate with the OTP code is hitting both onSuccess and isConnected == true then that should be a logged in user. If the user is not logged in, then isConnected shouldn't be true and should likely still be in an authenticating state (similar to how magic link used to be in an email_authenticating state). I imagine the signer would similarly be in an email_awaiting_otp state and once authenticate returns successfully, it should update the SignerStatus to complete

[moldy530]

just tried it out on a local branch with the delay removed altogether and seems to work without issue, so this might actually just be me missing context. Is this is a it's "too fast" situation?

[jcaleb4]

Quote reply
Reference i

@moldy530 I should have add some context, sorry about that.
This PR is just to delay the display of the authenticated view for OTP authenticated users enough time so we can display the "validated" view in the OTP flow.

Without the delay, the user can never see that view because right after the login, we switch the UI automatically.

[moldy530]

That's super helpful context, thanks @jcaleb4!!

Lemme think about the sessionType thing a little because I'm not 100% on it, but seems it's probably fine

[moldy530]

so one thing you could do in the ui-demo since we don't want to introduce the delay in root components (which this PR solves), is using something like a usePrevious hook an track the last value of the AuthContext step. Something like "if current step is complete and last step was otp_verify, then add a delay"

could be worth timeboxing. my only motivation for doing that is that this PR does a good job of isolating behaviour and interfaces that are ui-demo specific, and if we can truly isolate this logic without adding stuff to the core signer package that's JUST in service of the ui-demo that'd be amazing

[jcaleb4]

so one thing you could do in the ui-demo since we don't want to introduce the delay in root components (which this PR solves), is using something like a usePrevious hook an track the last value of the AuthContext step. Something like "if current step is complete and last step was otp_verify, then add a delay"

could be worth timeboxing. my only motivation for doing that is that this PR does a good job of isolating behaviour and interfaces that are ui-demo specific, and if we can truly isolate this logic without adding stuff to the core signer package that's JUST in service of the ui-demo that'd be amazing

I can take a look at that approach, I did try several ways but some of them were inconsistent when reloading after the user is already authenticated and some other problems, but I can retake a look to see if I can make it work without adding a new method into the signer

[jcaleb4]

@moldy530 I did some refactors, turns out we don't even need the usePrevious hook, and now the delay lives only in the otp.tsx file account-kit/react/src/components/auth/card/loading/otp.tsx, lines 15 and 44.
Now we will wait for the "complete" auth step type instead of just getting the user object, this way we can control when to set the authentication flow as "complete" and immediately after, the UI changes to the authenticated view.

Thank you for the feedback! I feel a lot better with this implementation :)

[moldy530]

Gotcha, can we confirm with Will and Julia that 3 seconds is an acceptable delay to apply globally? I don't want devs to end up feeling like this is too slow in the future. Maybe 250-500ms is better as that's a typical range for animations