Skip to content

perf(web): load the wallet and payment SDKs on demand - #14567

Open
dylanjeffers wants to merge 1 commit into
perf/lazy-react-virtualizedfrom
perf/lazy-wallet-modals
Open

perf(web): load the wallet and payment SDKs on demand#14567
dylanjeffers wants to merge 1 commit into
perf/lazy-react-virtualizedfrom
perf/lazy-wallet-modals

Conversation

@dylanjeffers

Copy link
Copy Markdown
Contributor

3 of 4 in a stack reducing the web entry chunk. Based on #14566. This is the one that needs real review — it touches the auth path and the root provider.

What

ReownAppKitModal runs new WagmiAdapter(...), new SolanaAdapter() and createAppKit(...) at module scope, so a single static import anywhere in the eager graph pinned @reown/*, @walletconnect/*, wagmi and @solana/web3.js into the entry chunk — for every visitor, including everyone who never opens a wallet. @coinflowlabs/react (which bundles the nsure-ai fraud SDK) was there for the same reason.

Together, ~1.9 MB of the entry chunk.

The surprising part: this was on the auth path

services/audius-sdk/auth.ts dereferenced wagmiAdapter.wagmiConfig at module scope, so every email/password user loaded the entire wallet stack to discover they didn't need it.

It now returns to Hedgehog before loading AppKit unless localStorage shows a persisted wallet connection. That probe deliberately errs toward loading: a false negative would silently downgrade an external-wallet user to Hedgehog (a correctness bug), while a false positive only costs a chunk fetch.

Why WagmiProvider stays mounted

It keeps a lightweight bootstrap config and swaps in the adapter's config once AppKit loads. Making the provider itself conditional would remount the entire app the moment a wallet appeared; swapping a context value does not. The bootstrap config sets storage: null so it can't clobber the real config's persisted wagmi.store entry.

Why lazy modal registration is safe

nice-modal-react's NiceModalPlaceholder filters the registry by currently visible ids:

var visibleModalIds = Object.keys(modals).filter(id => !!modals[id]);
var toRender = visibleModalIds.filter(id => MODAL_REGISTRY[id])

So a registered-but-never-shown modal never mounts and its hooks never run — the cost was always the static import graph, not runtime.

Registration moved out of each modal module on purpose. If they still self-registered, the dynamic import would overwrite MODAL_REGISTRY mid-flight and React would swap the element type under an open modal, remounting it and losing its state. The Suspense boundary is local because NiceModal.Provider mounts its placeholder outside the only boundary in routes.tsx.

Known limitation

CoinflowPurchaseProtection in routes.tsx is now lazy but still renders unconditionally, so the chunk is still fetched at startup — it's off the entry chunk's parse path rather than deferred outright. Rendering it only on purchase-capable routes would defer it properly, but that's a call for whoever owns payments, since early initialization may be deliberate.

⚠️ Needs QA

External wallet connect / disconnect / sign-in could not be exercised without a real wallet. The Hedgehog (email/password) path is verified: app boots, no console errors, AppKit chunk confirmed not fetched on load, and confirmed to load on demand when a wallet modal opens.

🤖 Generated with Claude Code

ReownAppKitModal runs `new WagmiAdapter(...)`, `new SolanaAdapter()` and
`createAppKit(...)` at module scope, so a single static import anywhere in the
eager graph pinned @reown/*, @walletconnect/*, wagmi and @solana/web3.js into
the entry chunk -- for every visitor, including everyone who never opens a
wallet. @coinflowlabs/react (which bundles the nsure-ai fraud SDK) was there for
the same reason.

Together these were ~1.9 MB of the entry chunk.

The surprising edge was auth: services/audius-sdk/auth.ts dereferenced
`wagmiAdapter.wagmiConfig` at *module scope*, so every email/password user
loaded the entire wallet stack to discover they did not need it. It now returns
to Hedgehog before loading AppKit unless localStorage shows a persisted wallet
connection. That probe deliberately errs toward loading: a false negative would
silently downgrade an external-wallet user to Hedgehog, while a false positive
only costs a chunk fetch.

WagmiProvider stays mounted with a lightweight bootstrap config and swaps in the
adapter's config once AppKit loads. Making the provider itself conditional would
remount the entire app the moment a wallet appeared; swapping a context value
does not. The bootstrap config sets `storage: null` so it cannot clobber the
real config's persisted `wagmi.store` entry.

The modals are registered lazily. This is safe because nice-modal-react's
NiceModalPlaceholder filters the registry by *currently visible* ids, so a
registered-but-never-shown modal never mounts and its hooks never run -- the
cost was always the static import graph, not runtime. Registration moved out of
each modal module on purpose: if they still self-registered, the dynamic import
would overwrite MODAL_REGISTRY mid-flight and React would swap the element type
under an open modal, remounting it and losing its state. The Suspense boundary
is local because NiceModal.Provider mounts its placeholder outside the only
boundary in routes.tsx.

CoinflowPurchaseProtection in routes.tsx is now lazy too. It still renders
unconditionally, so the chunk is still fetched at startup -- it is off the entry
chunk's parse path rather than deferred outright. Rendering it only on
purchase-capable routes would defer it properly, but that is a call for whoever
owns payments, since early initialization may be deliberate.

NEEDS QA: external wallet connect / disconnect / sign-in, which could not be
exercised without a real wallet. The Hedgehog (email/password) path is verified.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@changeset-bot

changeset-bot Bot commented Aug 18, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: d7eba56

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant