Convertitore gratuito da HTML a JSX/React

Come funziona

1. Incolla HTML: inserisci uno snippet HTML standard, div, form, tabelle o blocchi completi, nell'area di input.
2. Scegli le opzioni: attiva il wrapping in React Fragment e il pretty-print secondo le esigenze.
3. Ottieni il JSX istantaneamente: il convertitore trasforma automaticamente class → className, for → htmlFor, le stringhe style in oggetti style e chiude i tag auto-chiudenti.
4. Copia nel tuo progetto: incolla l'output JSX direttamente nei tuoi componenti React.

Perché usare HTML → JSX?

Quando si migrano template HTML a React, la conversione manuale è soggetta a errori. Dimenticare un singolo className o lasciare un tag non chiuso interrompe il build. Questo convertitore gestisce automaticamente ogni cambiamento richiesto, inclusa la conversione dei nomi di proprietà CSS come background-color in camelCase backgroundColor negli attributi style, la trasformazione delle stringhe di gestori di eventi in riferimenti a funzioni e la corretta auto-chiusura degli elementi void. Velocizza la prototipazione, le migrazioni di codice, e aiuta gli sviluppatori meno familiari con le differenze di sintassi JSX.

Conversioni chiave

• class → className, richiesto nei componenti React
• for → htmlFor, per gli elementi label
• stringhe style → oggetti, es. "color:red" → {color:'red'}
• Tag auto-chiudenti, <br> → <br />
• Wrapping con Fragment, <>…</> esterno opzionale

Cos'è davvero JSX

JSX sta per «JavaScript XML.» È un'estensione sintattica di JavaScript inventata da Jordan Walke a Facebook nel 2013 come parte del primo annuncio di React a JSConf US. JSX consente di scrivere markup simile a XML direttamente all'interno del codice JavaScript, <div className="hello">World</div>: e un transpiler (oggi quasi sempre Babel) lo compila in semplici chiamate di funzione: React.createElement('div', {className: 'hello'}, 'World'). Il browser non vede mai JSX direttamente; quello che viene inviato è JavaScript regolare.

La motivazione originale di Walke era che i linguaggi di template (Mustache, Handlebars, le vecchie direttive di Angular) erano cittadini di seconda classe del linguaggio ospitante; non potevano usare nativamente i loop, le condizioni o le variabili di JavaScript, quindi ognuno reinventava i propri. JSX ha invertito la relazione: invece di template che a volte usano JavaScript, ha dato JavaScript che a volte usa il markup. Il fatto che {condition && <Item />} sia una normale espressione JS che restituisce un elemento React è l'idea portante.

Da React 17 (ottobre 2020), il runtime JSX automatico significa che non è più necessario inserire import React from 'react' in ogni file che usa JSX; Babel inserisce le importazioni del runtime automaticamente. JSX è stato adottato anche ben oltre React: Preact, Solid, Qwik, Hono JSX, Million, Lit e TypeScript con .tsx consumano tutti la stessa sintassi. La bozza di specifica JSX su facebook.github.io/jsx è intenzionalmente framework-agnostica.

L'elenco completo delle differenze HTML→JSX

• Rinominazioni di parole riservate. class → className (perché class è riservato in JS). for → htmlFor (stesso motivo, for è la parola chiave del ciclo). Questi sono i due casi in cui tutti vengono bruciati per primi.
• Tutti gli altri attributi usano il camelCase. tabindex → tabIndex, readonly → readOnly, maxlength → maxLength, contenteditable → contentEditable.
• Due importanti eccezioni restano in kebab-case. Gli attributi aria-* (aria-label, aria-hidden) e gli attributi data-* (data-testid) mantengono la forma HTML. Lo stesso vale per xmlns.
• I tag auto-chiudenti sono obbligatori per gli elementi void: <br> diventa <br />, <img> diventa <img />, <input> diventa <input />. JSX è rigido come XML dove HTML è permissivo.
• Gli stili inline prendono un oggetto, non una stringa. style="color: red; background-color: blue" diventa style={{ color: 'red', backgroundColor: 'blue' }}. Tre cose da notare: doppie parentesi graffe (una per l'espressione JSX, una per il letterale oggetto), nomi di proprietà in camelCase, valori stringa tra virgolette. I valori numerici in pixel omettono l'unità: marginTop: 16, non '16px'.
• I gestori di eventi usano il camelCase e prendono riferimenti a funzioni. onclick="handleClick()" diventa onClick={handleClick}: notare le parentesi mancanti. onClick={handleClick()} chiamerebbe handleClick al momento del render e assegnerebbe il suo valore di ritorno come gestore, il che è quasi sempre un bug.
• I commenti usano {/* … */} all'interno di JSX, non <!-- … -->. La sintassi dei commenti HTML non ha significato all'interno di JSX.
• I Fragment racchiudono più fratelli. Un componente deve restituire un'unica radice, quindi più elementi di primo livello hanno bisogno di <>…</> (o il più lungo <React.Fragment>…</React.Fragment>) avvolti attorno a loro.
• Il rendering condizionale usa espressioni JS. {isVisible && <Item />} renderizza l'elemento solo se la condizione è truthy; {condition ? <A /> : <B />} sceglie tra due opzioni.
• Le parentesi graffe nel testo devono essere escapate. La parentesi graffa letterale { all'interno del contenuto testuale JSX viene interpretata come l'inizio di un'espressione. Usare {'{'} o un'entità HTML equivalente.

SVG, accessibilità e altro

SVG funziona all'interno di JSX con la stessa regola camelCase per la maggior parte degli attributi, viewBox, strokeWidth, fillOpacity. Le eccezioni notevoli: xlink:href usa il formato speciale xlinkHref (ora deprecato a favore del semplice href), e xmlns rimane invariato. Gli attributi di accessibilità seguono la convenzione kebab-case propria di ARIA come eccezione: aria-label, aria-describedby, role rimangono così come scritti.

Per il CSS, l'oggetto inline style di JSX è un'opzione. La maggior parte dei codebase di produzione usa una delle tre alternative più ricche: CSS Modules (nomi di classe con scope per file compilati dal bundler), Tailwind CSS (classi di utilità che passano direttamente via className), o librerie CSS-in-JS come styled-components, Emotion o Vanilla Extract. Tailwind è diventata la scelta più comune nei nuovi progetti dal 2022; le classi Tailwind non necessitano di conversione quando si sposta HTML in JSX, passano come normali stringhe className.

Problemi comuni nella conversione

• Gestori di eventi inline che chiamano la funzione. onclick="alert(1)" in HTML di solito diventa onClick={() => alert(1)} in JSX, avvolto in una funzione freccia in modo che l'alert si attivi al clic, non al render. Un converter ingenuo che produce onClick={alert(1)} farà apparire l'alert al momento del render anziché quando l'utente fa clic. Questo converter gestisce i casi comuni ma vale la pena controllare l'output.
• I commenti HTML vengono eliminati. La maggior parte dei converter JSX rimuove i commenti HTML anziché tradurli nella forma {/* */}, perché questi ultimi funzionano solo in posizioni specifiche all'interno di JSX. Aggiungere i commenti manualmente dove si desidera.
• Le rinominazioni degli attributi SVG non sono sempre gestite dai converter automatici. stroke-width, fill-rule, clip-path, text-anchor hanno tutti bisogno di forme camelCase; controllare attentamente l'output se si incolla SVG da un set di icone come Heroicons o Lucide.
• Attributi booleani. <input disabled> in HTML diventa <input disabled /> in JSX. <input disabled="false"> in HTML è in realtà disabilitato (qualsiasi valore lo abilita), ma in JSX disabled={false} è correttamente disattivato; la semantica JSX è più sensata di quella HTML.
• Entità HTML. © funziona nel contenuto testuale JSX ma è preferibile usare il carattere Unicode letterale (©).   funziona allo stesso modo.
• Il caso tabindex. Deve essere tabIndex. Facile da dimenticare perché il valore è spesso 0 o -1 e sembra numerico, ma il nome dell'attributo richiede comunque il camelCase.

Quando si userebbe questo strumento

• Migrazione di template server-rendered a React. Incollare un blocco di HTML di un sito esistente e ottenere JSX è il caso d'uso canonico.
• Importare icone, badge o export da strumenti di design. Heroicons, Lucide, la funzione «Copy as SVG» di Figma forniscono tutti HTML/SVG grezzo che ha bisogno del passaggio di rinomina.
• Conversione di snippet Tailwind UI / Flowbite / DaisyUI dai loro esempi HTML a JSX per un progetto React. Le classi Tailwind passano invariate; solo gli attributi strutturali necessitano conversione.
• Onboarding di sviluppatori che conoscono HTML ma non JSX: vedere le regole meccaniche applicate automaticamente è più rapido che leggere un elenco di differenze.
• Prototipazione rapida quando si è abbozzato il markup in HTML semplice per scopi di sketching e lo si vuole all'interno di un componente React.

L'output funziona per qualsiasi consumatore JSX, React, Preact, Solid, Qwik, Hono JSX, Million, il template literal html di Lit (con piccole modifiche). Non funziona per React Native, che utilizza componenti primitivi nativi come <View> e <Text> anziché elementi HTML.

Altre domande

Qual è la differenza tra JSX e HTML?

HTML è un linguaggio di markup che il browser analizza direttamente. JSX è una sintassi di espressioni JavaScript che si compila in chiamate React.createElement; non raggiunge mai il browser come JSX. JSX sembra rigido come XML (ogni tag deve chiudersi, gli attributi usano camelCase) perché viene analizzato come espressioni JavaScript, non come HTML permissivo. La somiglianza visiva è intenzionale ma la semantica sottostante è molto diversa.

Devo ancora importare React in ogni file JSX?

Non da React 17 (ottobre 2020), che ha introdotto il runtime JSX automatico. Con esso, Babel inietta le importazioni runtime necessarie, quindi i file che usano solo JSX non hanno bisogno di import React from 'react' in cima al file. Il runtime classico è ancora disponibile per le toolchain più vecchie. La maggior parte dei nuovi progetti usa il runtime automatico.

Posso usare JSX senza React?

Sì. JSX è una sintassi generica con una bozza di specifica su facebook.github.io/jsx, e molti framework la consumano: Preact, Solid, Qwik, Hono JSX, Million, Lit e la variante htm con tagged-template. I framework differiscono in ciò in cui JSX viene compilato (Preact usa h(…), Solid si compila in primitive reattive a grana fine, ecc.) ma la sintassi è condivisa.

Perché style prende un oggetto invece di una stringa?

Perché la sintassi delle espressioni JSX fornisce già le parentesi graffe per incorporare valori JavaScript, e un oggetto letterale è la rappresentazione JS più naturale di un insieme di proprietà. L'oggetto style consente anche numeri (la maggior parte riceve automaticamente px) ed espressioni JS, cosa che una stringa non può fare. Il compromesso è la sintassi leggermente scomoda della doppia parentesi graffa style={{ … }}: parentesi esterne per «questa è un'espressione JSX», parentesi interne per il letterale oggetto.

Vengono inviati dati a un server?

No. La logica di conversione è puro JavaScript che percorre la stringa HTML e riscrive gli attributi, tutto nel browser. L'HTML incollato non lascia mai la pagina, utile quando si migrano template interni proprietari o markup di componenti con endpoint API incorporati.