UX de Transação
Toasts, confirmações, retries e decodificação de erros para envios voltados ao usuário.
Receita
type TxState = "idle" | "building" | "signing" | "sending" | "confirmed" | "failed";Quando usar:
- Qualquer botão que dispara aprovação da carteira.
- Reduzir tickets de suporte por falhas obscuras.
- Polimento profissional em lançamentos mainnet.
Exemplo Prático
"use client";
import { useState } from "react";
export function useTxToast() {
const [state, setState] = useState<TxState>("idle");
const [signature, setSignature] = useState<string | null>(null);
const [error, setError] = useState<string | null>(null);
async function run(sendFn: () => Promise<string>) {
try {
setError(null);
setState("signing");
const sig = await sendFn();
setSignature(sig);
setState("confirmed");
return sig;
} catch (e) {
setError(e instanceof Error ? e.message : "Transaction failed");
setState("failed");
throw e;
}
}
return { state, signature, error, run };
}O que isso demonstra:
- Máquina de estados explícita para spinners de UI.
- Captura signature para link do explorer.
- Diferencie rejeição da carteira vs erro de programa na camada de UI.
Aprofundamento
Como Funciona
- Simule antes de assinar para mapear logs do programa em texto.
- Mostre link do explorer em confirmed.
- Retry com blockhash fresco em erros de expiração.
- Desabilite submits duplicados enquanto em voo.
Erros Comuns
- Toast genérico "failed" - usuários tentam de novo às cegas. Correção: decodifique logs de simulação.
- Sem estado pending - cliques duplos. Correção: desabilite botão.
- Assumir finalized instantâneo - sucesso prematuro. Correção: rotule nível de commitment.
- Link do explorer ausente - atrito de suporte. Correção: template de URL com cluster.
- Loop infinito de retry - mesmo erro de programa. Correção: limite retries; mostre orientação de correção.
Alternativas
| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| Email em confirmed | Ops de alto valor | Txs de jogo consumer |
| Envio silencioso em background | Analytics | Transferências iniciadas pelo usuário |
FAQs
App Router?
Providers em client layout.tsx; pages misturam server + client components.
Secrets?
Env de servidor só para keypairs; NEXT_PUBLIC_ para URLs de RPC.
kit 7.0.0?
Todos os exemplos usam @solana/kit, não web3.js v1.
Carteira?
Assinatura apenas em client components.
Cache?
Revalide leituras on-chain com cuidado - a chain é fonte da verdade.
Actions?
Endpoints HTTPS retornando JSON de Solana Actions.
Mobile?
App React Native separado com MWA.
Testes?
Surfpool para integração; mock RPC em testes unitários.
Mainnet?
Arquivos env e program IDs separados.
Erros?
Decodifique logs de simulação para mensagens voltadas ao usuário.
Relacionado
- Assinatura no Lado do Client - pipeline de envio
- Assinando e Enviando - confirmação kit
- Depurando Transações com Falha - ops
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.