Convertisseur HTML vers JSX

Convertisseur HTML vers JSX — JSX Prêt pour React depuis du HTML Brut

Collez n'importe quel snippet HTML et obtenez du JSX qui compile proprement dans un composant React. Le convertisseur gère chaque différence courante : renomme class en className et for en htmlFor, parse les strings de style en objets JavaScript avec clés camelCase, auto-ferme les void elements, convertit les attributs SVG avec tirets, réécrit les commentaires HTML en expressions JSX, et enveloppe les event handlers dans des arrow functions. Optionnellement enveloppe la sortie dans un Fragment ou un function component complet, avec indentation ajustable et une entrée pour le nom du composant.

Pourquoi React ne peut-il pas simplement accepter HTML directement ?

JSX est une extension syntaxique de JavaScript, pas HTML — et JavaScript a ses propres mots réservés qui entrent en conflit avec les noms d'attributs HTML. Les deux grands sont :

- **class** — déjà utilisé en JavaScript pour les déclarations de classe (`class MyComponent extends React.Component`).
- **for** — utilisé dans les boucles for (`for (let i = 0; ...)`).

React a renommé ces attributs en **className** et **htmlFor** pour éviter le conflit. Chaque autre renommage camelCase (tabIndex, readOnly, autoComplete…) suit le même modèle : JSX utilise camelCase pour les propriétés DOM à plusieurs mots car les expressions JSX sont évaluées comme des littéraux d'objet JavaScript, où les tirets ne sont pas autorisés dans les noms de propriétés.

React 19 a effectivement commencé à accepter de nombreux attributs avec orthographe HTML (`tabindex`, `readonly`) à runtime, mais le linter et la plupart des conventions de code veulent encore la forme camelCase. Ce convertisseur produit du camelCase strict pour la compatibilité avec React 16 à 19.

Comment style se convertit-il de string à objet ?

Les strings style HTML sont des paires clé-valeur séparées par des points-virgules :

```
style="margin-top: 16px; background: #eee; font-weight: 700;"
```

JSX nécessite un objet JavaScript dont les clés sont en camelCase et dont les valeurs sont soit des strings, soit des nombres :

```
style={{ marginTop: '16px', background: '#eee', fontWeight: 700 }}
```

Le convertisseur divise sur les points-virgules, divise chaque paire sur son premier deux-points, convertit le nom de propriété en camelCase (`margin-top` → `marginTop`), et décide s'il faut citer la valeur. Les valeurs purement numériques (`16`, `700`, `1.5`) sont émises non citées — React traite les valeurs numériques pour les propriétés de taille comme px implicitement. Tout le reste est cité comme string.

Quelques comportements subtils :

- Les propriétés CSS personnalisées (`--my-var`) gardent leurs tirets — elles sont citées comme clés string : `'--my-var': 'value'`.
- `!important` est supprimé (le style JSX ne le supporte pas nativement ; utilisez plutôt une vraie classe CSS).
- Les préfixes vendor sont aussi mis en camelCase : `-webkit-transform` → `WebkitTransform` (notez le W majuscule, par convention React).

Si vous préférez coller le style comme string brut et ne pas convertir, décochez 'Convertir attr style en objet' — JSX l'accepte comme string, bien que la plupart des linters React s'en plaignent.

Comment le convertisseur gère-t-il les event handlers comme onclick ?

En HTML, les attributs event handler contiennent une chaîne de JavaScript que le navigateur évaluera au déclenchement de l'événement :

```
<button onclick="track('signup'); openModal()">Sign up</button>
```

Les event handlers JSX ont besoin d'une référence de fonction (ou d'une arrow function inline), pas d'une chaîne. Le convertisseur enveloppe le code original dans une arrow function pour qu'il continue à s'exécuter :

```
<button onClick={() => { track('signup'); openModal() }}>Sign up</button>
```

C'est intentionnellement un wrap littéral — il préserve la logique existante pour que le snippet compile, mais vous voudrez généralement refactoriser cela en un handler nommé :

```
<button onClick={handleSignup}>Sign up</button>
```

L'option 'Supprimer event handlers' enlève entièrement les handlers inline si vous préférez les attacher vous-même dans le fichier JSX. Utile lors de la migration de markup legacy avec handlers inline partout.

Le renommage de l'attribut lui-même est mécanique : `onclick` → `onClick`, `onmouseover` → `onMouseOver`, `oninput` → `onInput`, etc. Le convertisseur reconnaît tout attribut `on[a-z]+` comme event handler.

Pourquoi je vois parfois {'{'} et &lt; dans la sortie ?

JSX est parsé comme JavaScript, donc les caractères `{`, `}`, `<`, et `>` ont une signification syntaxique dans le markup :

- `{` ouvre une expression JavaScript
- `<` ouvre une balise JSX

Si ces caractères apparaissent dans du contenu texte, JSX les traite comme du code, pas du texte. Le convertisseur les échappe pour que React les rende comme caractères littéraux :

- Un `{` littéral devient `{'{'}`
- Un `}` devient `{'}'}`
- `<` devient `&lt;` (entité HTML, que JSX préserve dans le contenu texte)
- `>` devient `&gt;`

Cela importe surtout pour les blocs d'affichage de code. Si vous collez `<code>const x = { a: 1 };</code>`, la sortie JSX lira `<code>const x = {'{'} a: 1 {'}'};</code>` — moche mais fonctionnellement correct.

Pour la production, utilisez un composant dédié de coloration syntaxique (Prism, Shiki, Highlight.js) ou enveloppez le code littéral dans `<pre>{`code ici`}</pre>` avec un template literal — les expressions JSX peuvent contenir n'importe quelle string. L'échappement du convertisseur est le repli sûr quand vous ne voulez pas refactoriser.

Que fait le convertisseur avec les attributs SVG ?

SVG a des dizaines d'attributs de présentation qui utilisent des tirets : `stroke-width`, `fill-opacity`, `text-anchor`, `font-family`, etc. En JSX tous doivent être en camelCase : `strokeWidth`, `fillOpacity`, `textAnchor`, `fontFamily`.

Le convertisseur reconnaît la liste standard des attributs SVG avec tirets (environ 35, selon l'API React DOM) et ne convertit que ceux-là — les attributs `data-*` et `aria-*` gardent toujours leurs tirets car JSX autorise les tirets spécifiquement dans ces deux espaces de noms.

Quelques attributs SVG sont *déjà* en camelCase en HTML et restent inchangés : `viewBox`, `preserveAspectRatio`, `gradientUnits`, `xmlns`. La spécification HTML5 a défini ceux-ci comme sensibles à la casse CamelCase, et JSX en hérite.

Un snippet SVG complet d'une bibliothèque d'icônes typique — paths, transforms, gradients — se convertit proprement en un collage. Le log de transformations vous montre quels attributs ont été touchés afin que vous repériez tout ce qui sort de l'ordinaire.

Dois-je envelopper la sortie dans un Fragment ou un composant ?

Choisissez selon où va le markup :

- **Aucune enveloppe** — le convertisseur produit du JSX brut que vous pouvez coller n'importe où. Idéal pour intégrer dans la sentence return d'un composant existant.
- **Fragment (`<></>`)** — enveloppe plusieurs éléments de niveau supérieur dans un React Fragment. Utilisez quand votre HTML a plus d'une racine (par ex., deux divs frères) ; JSX exige une seule racine, et les Fragments n'ajoutent pas d'élément enveloppant au DOM.
- **Function component** — enveloppe tout dans une définition `function MyComponent() { return (...); }` complète. Idéal pour le scaffolding rapide en commençant un nouveau fichier de composant depuis un mockup de design.

Le champ nom de composant n'est honoré qu'en mode composant. Il est restreint aux caractères alphanumériques et doit commencer par une majuscule (convention React — les composants doivent commencer par une lettre majuscule pour que JSX les distingue des balises HTML).

Aucun des modes d'enveloppe n'injecte `import React from 'react'` — React moderne (17+) avec le JSX transform n'en a pas besoin. Si vous êtes sur du React plus ancien, ajoutez l'import manuellement.

Et les attributs React DOM que je m'attendrais à voir mais qui n'y sont pas ?

Le convertisseur gère le cas commun. Quelques attributs ont des nuances à connaître :

- **value vs defaultValue** — En HTML, `<input value="x">` définit la valeur initiale. En JSX, cela crée un input *contrôlé* qui doit avoir un onChange. Si vous voulez le comportement HTML (valeur initiale, puis l'utilisateur peut éditer), utilisez `defaultValue="x"`. Le convertisseur laisse `value` tranquille — vous devrez décider contrôlé vs non contrôlé au cas par cas.
- **checked vs defaultChecked** — Même distinction contrôlé/non contrôlé pour checkboxes/radios.
- **selected sur `<option>`** — Utilisez plutôt `value` sur le `<select>` parent, c'est l'idiome React.
- **dangerouslySetInnerHTML** — La seule façon de React pour définir HTML directement. Le convertisseur ne le génère pas ; il convertit le contenu texte en nœuds texte JSX à la place.
- **ref** — Une prop spécifique à React que le convertisseur ne génère pas ; ajoutez manuellement lors du câblage du focus ou des mesures DOM.

Le convertisseur gère la migration *syntaxique* — faire que votre HTML compile comme JSX. La migration *sémantique* (inputs contrôlés, refs, state) est quelque chose que vous ajouterez par-dessus selon ce que le composant doit faire.

Ce convertisseur est-il privé ?

Oui. La conversion se passe entièrement dans votre navigateur :

- La page utilise le DOMParser intégré du navigateur pour parser le HTML — aucune API distante n'est appelée.
- Les règles de transformation sont du code JavaScript qui s'exécute localement.
- Le bouton Exemple remplit le textarea avec une string intégrée ; rien n'est téléchargé.
- Le bouton Copier utilise l'API du presse-papiers du navigateur.
- Aucune télémétrie de quel HTML vous avez collé.

Vérifiez en ouvrant DevTools → Réseau et en regardant le panneau pendant que vous cliquez sur Convertir — aucune requête ne se déclenche. Cela signifie aussi que l'outil fonctionne hors-ligne une fois la page chargée, donc vous pouvez convertir des snippets de markup dans un hôtel, dans un avion, ou derrière un pare-feu d'entreprise sans vous soucier d'où va votre code.

Caractéristiques Clés

• DOMParser natif du navigateur pour un parsing HTML robuste (gère markup cassé/non fermé proprement)
• Renommage class → className et for → htmlFor
• tabindex → tabIndex, readonly → readOnly, et 25+ autres remappings camelCase
• Event handlers (onclick, onchange, etc.) renommés en camelCase et enveloppés dans arrow functions
• Strings de style inline parsées en objets JavaScript avec clés camelCase
• Attributs SVG avec tiret (stroke-width, fill-opacity, text-anchor) convertis en camelCase
• Void elements (br, img, input) auto-fermés pour le mode strict JSX
• Commentaires HTML convertis en expressions JSX {/* ... */}
• Attributs booléens (disabled, checked, required) émis sans valeur
• Attributs data-* et aria-* préservés selon la spec JSX
• Trois modes d'enveloppement : aucun, Fragment, ou function component complet
• Indentation configurable : 2 espaces, 4 espaces, ou tabs
• Champ nom de composant pour le mode function-component
• Option de suppression des event handlers pour migration propre
• Log de transformations montre exactement ce qui a changé
• JavaScript pur — aucune bibliothèque externe
• Fonctionne hors-ligne après le premier chargement
• 100% côté client — votre HTML reste dans votre navigateur