fix(faucet): keep the send-to-address field visible once a wallet connects - #8
Merged
Merged
Conversation
…nects It lived only in the `!isConnected` branch, which had two faults. THE VISIBLE ONE. Wallet state rehydrates from localStorage a beat after mount, so anyone with a previously-connected wallet saw the section render and then vanish as `isConnected` flipped to true. It read as the page flashing the new UI and reverting to the old one, and it reproduced in Chromium but not Firefox purely because a wallet was connected in one and not the other. Nothing to do with caching or the deploy, which is where I looked first. THE WORSE ONE. Connected visitors never got the feature at all. Funding an agent's address has nothing to do with whether YOUR wallet is connected, yet only disconnected visitors could see the field — which excludes most returning users, and plausibly most of the people being asked to unblock an agent. Now mounted in both branches, so it cannot disappear and cannot be missed. The divider label adapts: "or" when disconnected, "or send to another address" when connected, where it is a second distinct action rather than an alternative to connecting. Deliberately NOT fixing the top half of the card. `useConnection` exposes `isReconnecting` and a skeleton would suppress the Connect-button flash too, but with `reconnectOnMount` the status passes through `reconnecting` on every load even when nothing is stored — so a skeleton would introduce a flash for visitors who currently get an instant button. That transition is pre-existing and affects all three faucets equally; it wants its own change. fmt --check, typecheck, type-aware lint and build all pass.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
The paste-an-address field lived only in the
!isConnectedbranch ofFaucetCard, which had two faults.The visible one. Wallet state rehydrates from localStorage a beat after mount, so anyone with a previously-connected wallet saw the section render and then vanish as
isConnectedflipped to true:It read as the page flashing the new UI and reverting to the old one, and it reproduced in Chromium but not Firefox purely because a wallet was connected in one and not the other. Nothing to do with caching or the deploy.
The worse one. Connected visitors never got the feature at all. Funding an agent’s address has nothing to do with whether your wallet is connected, yet only disconnected visitors could see the field — which excludes most returning users, and plausibly most of the people being asked to unblock an agent.
Change
The section is now mounted in both branches, so it cannot disappear and cannot be missed. The divider label adapts:
orwhen disconnected,or send to another addresswhen connected, where it is a second distinct action rather than an alternative to connecting.Deliberately out of scope
useConnectionalso exposesisReconnecting, and a skeleton would suppress the Connect-button flash on the top half of the card too. Left alone: withreconnectOnMountthe status passes throughreconnectingon every load even when nothing is stored, so a skeleton would introduce a flash for visitors who currently get an instant button. That transition is pre-existing and affects all three faucets equally.Verification
pnpm fmt --check,pnpm typecheck, type-awareoxlintandpnpm buildall pass.To check once deployed: in Chromium with a wallet connected, the field should stay put rather than flash and vanish, and should sit under an
or send to another addressdivider.