useDynamicContext(), exposed a useIsLoggedIn() flag, and rendered the profile, settings, and account-deletion screens inside the DynamicUserProfile widget. The JavaScript SDK gives you the same user data through useUser() (and getDefaultClient().user), a set of focused functions for updating and deleting the account, and leaves every screen to you.
Building the profile, settings, and delete screens is the same in any JavaScript SDK app, so it isn’t repeated here: User profile & settings (Building UI) covers reading, updating, and deleting with full code. This page is the React→JavaScript translation plus the migration-specific behavior.
Reading the user
- No
isLoggedInboolean — you define what “signed in” means. There’s no single flag anymore; your app decides the condition and composes it from SDK helpers: whether a user exists (useUser()/getDefaultClient().userreturns theUserornull), whether a wallet is connected (isAnyWalletAccountConnected()), and so on. In vanilla JS, recompute it on theuserChangedevent (viaonEvent— see the events catalog). - Reading the JWT directly isn’t recommended.
getDefaultClient().tokenis the current JWT ornull, but prefer letting the SDK attach auth to your requests rather than reading the token yourself. In cookie-based environments the token lives in an httpOnly cookie and is never exposed, sotokenis alwaysnull— send credentialed requests instead (see the Cookies guide).
Updating, refreshing, deleting
updateUser({ userFields })can return a verification. When the change touches a contact method that needs re-verification (email or phone), it resolves with anOTPVerificationobject instead of applying immediately — prompt for the code and complete verification before treating the change as saved. Other fields (firstName,username,metadata, …) apply directly. User profile & settings (Building UI) shows the returned object’s shape and how to tell whether the code went to the email or the phone (otpVerification.emailvsotpVerification.phoneNumber).refreshAuth()refetches the user and rotates the session token in one call — use it after a server-side change or to extend a session (see Refresh auth).deleteUser()has no confirmation UI. It permanently removes the account, so build your own “are you sure?” step before calling it.
Verified credentials and login methods
TheUser carries a verifiedCredentials array — the same structure as the React SDK. Each credential has a format (a few examples: 'email', 'phoneNumber', 'oauth', 'blockchain', 'passkey', 'externalUser', 'totp') telling you how the user proved that identifier, so you distinguish login methods by reading format rather than a dedicated flag. For the full set of formats and how to read them — including lastVerifiedCredentialId for the most recent login — see Distinguishing login methods.
Authorization
- Gate on
checkUserScopes({ scopes, user })— it returns whether the user was granted every scope you pass (see Token scopes for the available scopes). The React SDK’sAccessBlockedView/NoAccessscreens are gone; render your own blocked state when the check fails. - Linked social accounts are read with
getUserSocialAccounts()/useGetUserSocialAccounts()and detached withunlinkSocialAccount().unlinkSocialAccount()requires aCredentialunlinkelevated access token with no fallback — see Social account linking for thecheckStepUpAuth()pattern.
What you now build
TheDynamicUserProfile widget rendered these; in the JavaScript SDK they are yours:
- Profile & settings screens — the form that edits
userFieldsand callsupdateUser(). Follow User profile & settings (Building UI) for the full flow. - Account deletion — the confirmation dialog that gates
deleteUser(). - Access-blocked screen — what to show when
checkUserScopes()fails. - Connected apps — the list of linked social accounts with unlink controls, built on social linking.
Errors you now own
See also
- User profile & settings (Building UI) — build the profile and settings screens
- Handling blocked wallets (Building UI) — build the access-blocked experience
- Basic setup — the client, provider, and events → promises shift
- Post-login user setup — get a freshly authenticated user ready for your app
- Cookies — cookie-based sessions and why
tokenisnull