Add Embed Faucet route and update related components#891
Add Embed Faucet route and update related components#891ultraviolet10 wants to merge 3 commits intomasterfrom
Conversation
Deploying happychain with
|
| Latest commit: |
ed4033c
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://a54e673e.happychain.pages.dev |
| Branch Preview URL: | https://aritra-faucet-page.happychain.pages.dev |
| key: "topup", | ||
| to: "/embed/faucet", | ||
| label: "Top Up", | ||
| icon: CreditCardIcon, |
There was a problem hiding this comment.
Text should say "Faucet" too
There was a problem hiding this comment.
topup should stay I think (and stay disabled) faucet is separate and exclusive feature to testnet
But besides that, I'm of two minds on this. It look kinda better as a tab (feels very empty otherwise). Also, it's kinda cool if we can get the balance show up top to refresh when the faucet hits. Let's discuss. |
I think it does this on master now (so assuming it works here, but i'm rate limited now 😓 ) I think i like it as a tab better but with that said, our tabs could be good to be routes: https://ark-ui.com/docs/components/tabs#router-controlled-tabs |
|
Aight, let's keep as a tab for now! |

Linked Issues
closes https://linear.app/happychain/issue/HAPPY-509/faucet-available-via-top-button-instead-of-a-popup
Description
This PR moves the faucet functionality from a tab in the wallet interface to its own dedicated route at
/embed/faucet. The change improves the user experience by making the faucet accessible via a "Top Up" action button in the main interface.Key changes:
/embed/faucetthat hosts the faucet functionalityUseTurnstileArgstype nameToggle Checklist
Checklist
Basics
norswap/build-system-caching).Reminder: PR review guidelines
Correctness
C1. Builds and passes tests.
C2. The code is properly parameterized & compatible with different environments (e.g. local,
testnet, mainnet, standalone wallet, ...).
C3. I have manually tested my changes & connected features.
C4. I have performed a thorough self-review of my code after submitting the PR,
and have updated the code & comments accordingly.
Architecture & Documentation
(2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
Public APIS and meaningful (non-local) internal APIs are properly documented in code comments.
in a Markdown document.
make changesetforbreaking and meaningful changes in packages (not required for cleanups & refactors).