feat(next-template): route production onramp through vechain/onramp-proxy - #654
Conversation
…roxy - widgetUrlBuilder speaks both contracts: production uses onramp-proxy (GET, shared VeChain backend), staging keeps the vechain-kit-infra proxy (POST) so the preview env is unchanged - deploy-cloudfront reads NEXT_PUBLIC_TRANSAK_API_URL_PROD
📝 WalkthroughWalkthroughThe production deployment now uses a production Transak API secret. The widget URL builder uses a GET request with query parameters in production and keeps the existing POST flow for other environments. ChangesTransak production flow
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant widgetUrlBuilder
participant TransakAPI
Client->>widgetUrlBuilder: Request widget URL
widgetUrlBuilder->>TransakAPI: GET apiUrl with Transak query parameters
TransakAPI-->>widgetUrlBuilder: JSON response with url or error
widgetUrlBuilder-->>Client: Return url or throw error
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Size Change: 0 B Total Size: 9.02 MB ℹ️ View Unchanged
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
examples/next-template/src/app/providers/VechainKitProviderWrapper.tsx (1)
148-161: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winDon’t rely on query parameters in the production Transak onramp flow.
Transak direct widget URL query parameters are deprecated;
cryptoCurrencyCodeandnetworkbelong in the server-side widgetParams. If this production URL still works, it is an undocumented workaround and can drift from Transak’s supported flow.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@examples/next-template/src/app/providers/VechainKitProviderWrapper.tsx` around lines 148 - 161, Update the production Transak onramp flow around VechainKitProviderWrapper’s URLSearchParams construction to stop passing widget configuration through the direct widget URL. Move cryptoCurrencyCode and network into Transak’s server-side widgetParams mechanism, and retain only parameters supported by the production flow, including the existing fiatAmount handling.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@examples/next-template/src/app/providers/VechainKitProviderWrapper.tsx`:
- Around line 148-161: Update the production Transak onramp flow around
VechainKitProviderWrapper’s URLSearchParams construction to stop passing widget
configuration through the direct widget URL. Move cryptoCurrencyCode and network
into Transak’s server-side widgetParams mechanism, and retain only parameters
supported by the production flow, including the existing fiatAmount handling.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d8f99ff5-ff6b-460c-b536-31d3a336b9b0
📒 Files selected for processing (2)
.github/workflows/deploy-cloudfront.yamlexamples/next-template/src/app/providers/VechainKitProviderWrapper.tsx
…655) * fix(homepage): route production onramp through vechain/onramp-proxy #654 repointed deploy-cloudfront's NEXT_PUBLIC_TRANSAK_API_URL_PROD secret at vechain/onramp-proxy (GET contract) and fixed the next-template example's widgetUrlBuilder to match, but the actual production build (examples/homepage, deployed to vechainkit.vechain.org) was left on the old vechain-kit-infra POST/JSON contract — so the deployed widgetUrlBuilder now POSTs JSON to a GET-only endpoint and every production onramp call 405s. Ports the same production/staging branch already working in next-template. * fix(transak): widen the widget container to Transak's own 80dvh guidance Reported: the "Add card details" step rendered clipped/overlapping the quote screen underneath it inside the embedded widget. Root cause (confirmed against @transak/ui-js-sdk@1.0.0's actual runtime): in containerId mode the SDK always renders the iframe at width:100%; height:100% of its container — widgetWidth/widgetHeight config options are silently ignored in that mode (they only apply to the SDK's own standalone overlay, used when no containerId is passed). So the container's own CSS is what bounds the widget, and both copies of it (TransakCheckoutModal, TransakOnrampContent) capped it at maxH="620px" — well under Transak's own documented single-embed sizing of `height: 80dvh` (docs.transak.com/integration/web/iframe), which is closer to what the deeper flow steps (KYC, add-card-details) actually need. Raises both containers to 80dvh (560-900px clamp) to match. * fix(transak): widen the modal, add a loading spinner for the widget iframe Reported on the preview deploy: opening the widget showed a blank white container for a few seconds (the iframe loading Transak's remote app), and the whole flow felt cramped -- the modal wasn't using the available screen space. - useTransakCheckout: track `widgetReady`, flipped by the SDK's TRANSAK_WIDGET_INITIALISED event (previously unused). False from the moment the widget opens until the iframe has actually rendered. - TransakCheckoutModal / TransakOnrampContent: render a centered Spinner as a sibling overlay while `!widgetReady` -- never as a child of the SDK's own container div, since the SDK appends/removes the iframe via direct DOM calls (containerId mode) that would fight React for that node's children. - TransakCheckoutModal: BaseModal size 'sm' -> 'lg' (Transak's own single-embed sample uses a 500px-wide container; 'sm' was 384px). - AccountModal: the 'transak-onramp' content type now gets its own larger size/height ('lg', up to 90dvh) instead of the fixed 485px/'sm' every other AccountModal screen uses -- that fixed cap was squeezing an embedded external payment app (quote, KYC, add-card-details) into a size tuned for simple menu/settings screens. * feat(playground): add Payments example, total-balance-in-USD demo - New "Payments" page (mirrors the "Transactions" page's structure): PayWithTransakButton for the drop-in Buy VET button, plus a useTransakCheckout demo for a fully custom trigger. Added to the sidebar nav under Build, status NEW. - "Reading Data" page: new DemoSection for useTotalBalance -- one USD figure across liquid tokens + staking positions, the same total the AccountModal shows. - Wired transak config into the playground's VechainKitProviderWrapper (same dual-contract widgetUrlBuilder as the homepage example: prod -> vechain/onramp-proxy, staging -> vechain-kit-infra), gated on the new NEXT_PUBLIC_TRANSAK_* env vars (added to .env.example, all optional -- the Payments page degrades to the hook's built-in "not configured" error when unset, same as every other example integration here).
Converges the production fiat onramp on
vechain/onramp-proxy(shared VeChain backend, see vechain/onramp-proxy#29) while the preview env keeps the current vechain-kit-infra proxy.Changes
widgetUrlBuilderin the example wrapper branches onNEXT_PUBLIC_TRANSAK_ENVIRONMENT:production→GET {API_URL}/?provider=transak&address=…&os=web&theme=LIGHT¤cy=…&referrerDomain=…&fiatAmount=…→{url}(onramp-proxy contract)staging(preview) → existing POST contract, unchangeddeploy-cloudfront.yamlreads the URL from a new secretNEXT_PUBLIC_TRANSAK_API_URL_PROD(→https://onramp-proxy.vechain.org);deploy-preview.yamluntouched.Requires
NEXT_PUBLIC_TRANSAK_API_URL_PRODSummary by CodeRabbit