React
Pricing table in 10 minuti: componente React o da zero?
Una pricing table non è una griglia di prezzi: è una decisione. Ecco quando installare un componente, quando scriverlo da zero e i tre stati che quasi tutte le tabelle dimenticano.
In sintesi
- Prima definisci la decisione, poi disegni le colonne.
- Il componente pronto va bene se copre piano gratuito, piano evidenziato e stati mobile.
- Non dimenticare loading, errore e renewal: sono i punti in cui la pricing table perde soldi.
Una pricing table è una pagina di decisione. Il visitatore non sta leggendo un listino: sta cercando di capire quale piano è per lui, quanto rischia e cosa succede dopo. Se la tabella non risponde a queste tre domande, il numero di colonne non conta.
Puoi partire da un componente del catalogo o scriverla da zero. La scelta giusta dipende da quante variabili hai: piani, valute, tasse, trial, upgrade, downgrade, team seats.
Prima la decisione, poi la griglia
- Qual è il piano che vuoi vendere? Evidenzialo, ma non nascondere gli altri.
- Il prezzo è mensile, annuale o entrambi? Mostra il risparmio senza layout shift.
- Cosa include il piano? Una riga per beneficio, non un muro di check.
- Cosa succede dopo il clic? Trial, checkout, contatto: la CTA deve dirlo.
- Chi paga? Un individuo, un team, un’azienda: la copy cambia.
Il componente pronto vs la tabella da zero
| Caso | Componente pronto | Da zero |
|---|---|---|
| 3 piani, una valuta | Sì, in 10 minuti | Solo se hai un design molto specifico |
| Team seats e fatturazione | Sì, se il componente gestisce quantity | Spesso serve una API tua |
| Trial e upgrade in-app | Sì, se colleghi lo stato al backend | Sì, ma il costo è nel flusso, non nella tabella |
| Prezzi dinamici per paese | Sì, se il prezzo arriva da server | Sì, con più test |
I tre stati che quasi tutti dimenticano
Loading: la tabella non deve saltare quando arrivano i prezzi. Errore: se il checkout non risponde, il pulsante deve dire cosa fare. Renewal: l’utente deve sapere quando verrà addebitato e come disdire. Una pricing table che ignora questi tre stati è un mockup.
Una base React leggibile
Se scegli il componente, apri la scheda e controlla che il piano evidenziato sia un dato, non un colore hard-coded. Se scegli da zero, tieni i piani in un array e rendering in una mappa: aggiungere un piano non deve significare copiare tre blocchi di JSX.
const plans = [
{ id: "free", name: "Free", price: 0, featured: false },
{ id: "pro", name: "Pro", price: 24, featured: true },
{ id: "team", name: "Team", price: 79, featured: false },
];
export function Pricing({ plans }) {
return (
{plans.map((plan) => (
{plan.name}
{plan.price} € / mese
))}
);
}Per i pattern completi, piano centrale, toggle mensile/annuale, FAQ e CTA finale, usa le guide Pricing table designs e Monthly/annual billing toggles.
Domande frequenti
Quanto tempo serve per una pricing table?
Con un componente pronto, 10–20 minuti. Da zero, mezza giornata se includi stati, mobile e collegamento al checkout.
Meglio tre o quattro piani?
Tre piani sono più facili da confrontare. Il quarto ha senso solo se aggiunge un segmento reale, non se serve a far sembrare il piano centrale più conveniente.
Dove metto il toggle mensile/annuale?
Sopra le colonne, con il risparmio visibile e senza cambiare l’altezza della tabella quando cambia il periodo.
Il prezzo deve arrivare dal server?
Sì, se cambia per paese, valuta o promozione. Non duplicare i prezzi nel client: il server è la fonte.
Posso usare un componente del catalogo in un progetto commerciale?
Controlla la licenza mostrata sul record. EneUI riporta la licenza dichiarata a monte; se non è chiara, chiedi prima di spedire.