Hay algo que encuentro muy confuso cuando trabajo React.
Hay muchos ejemplos disponibles en Internet que usan .jsarchivos con react pero muchos otros usan .jsxarchivos.
He leído sobre .jsxarchivos y entiendo que simplemente te permiten escribir etiquetas html dentro de tu javascript. Pero lo mismo se puede escribir en .jsarchivos también.
Entonces, ¿cuál es la diferencia real entre estas dos extensiones .jsy .jsx?
Respuestas:
No hay ninguno cuando se trata de extensiones de archivo. Su bundler / transpiler / lo que sea se encarga de resolver qué tipo de contenido de archivo hay.
Sin embargo, hay algunas otras consideraciones al momento de decidir qué poner en una .jso un .jsxtipo de archivo. Como JSX no es JavaScript estándar, se podría argumentar que cualquier cosa que no sea JavaScript "simple" debería ir a sus propias extensiones, es decir, .jsxpara JSX y .tsTypeScript, por ejemplo.
.jsxno es un requisito
En la mayoría de los casos, solo es necesario el transpiler / bundler, que puede no estar configurado para funcionar con archivos JSX, ¡sino con JS! Por lo tanto, se ve obligado a usar archivos JS en lugar de JSX.
Y dado que reaccionar es solo una biblioteca para javascript, no hace ninguna diferencia que elija entre JSX o JS. ¡Son completamente intercambiables!
En algunos casos, los usuarios / desarrolladores también pueden elegir JSX en lugar de JS, debido al resaltado del código, pero la mayoría de los editores más nuevos también están viendo la sintaxis de reacción correctamente en los archivos JS.
Las etiquetas JSX ( <Component/>) claramente no son JavaScript estándar y no tienen un significado especial si las coloca dentro de una <script>etiqueta desnuda, por ejemplo. Por lo tanto, todos los archivos React que los contienen son JSX y no JS.
Por convención, el punto de entrada de una aplicación React suele ser .js en lugar de .jsx aunque contenga componentes React. También podría ser .jsx. Cualquier otro archivo JSX generalmente tiene la extensión .jsx.
En cualquier caso, la razón por la que hay ambigüedad es porque, en última instancia, la extensión no importa mucho, ya que el transpilador felizmente mastica cualquier tipo de archivos siempre que sean en realidad JSX.
Mi consejo sería: no te preocupes por eso.
var elem = <div>Text</div>;no es un elemento html estándar; no es compatible appendChild, classListy probablemente otras características html. Si desea etiquetas html directamente en javascript, es mejor usar el literal de plantilla (la tecla de retroceso `) junto con innerHtmlo outerHtml.
Además del hecho mencionado de que las etiquetas JSX no son javascript estándar, la razón por la que uso la extensión .jsx es porque con ella Emmet todavía funciona en el editor, ya sabes, ese complemento útil que expande el código html, por ejemplo ul> li en
<ul>
<li></li>
</ul>"emmet.includeLanguages": { "javascript": "javascriptreact" }pero sí, estoy de acuerdo en que el código JSX debería usar la extensión .jsx si es posible.
Como otros mencionados JSXno es una extensión estándar de Javascript. Es mejor nombrar su punto de entrada de la aplicación en función .jsde los demás componentes que puede usar .jsx.
Tengo una razón importante por la que estoy usando .JSXlos nombres de todos los componentes. En realidad, en un proyecto a gran escala con gran cantidad de código, si configuramos todos los componentes de React con .jsxextensión, será más fácil navegar a diferentes archivos javascript en todo el proyecto (como ayudantes, middleware, etc.) y usted sabe que esto es un componente React y no otros tipos del archivo javascript.
JSX no es JavaScript estándar, basado en la guía de estilo de Airbnb 'eslint' podría considerar este patrón
// filename: MyComponent.js
function MyComponent() {
return <div />;
}como advertencia, si nombró su archivo MyComponent.jsx, pasará, a menos que si edita la regla eslint, puede consultar la guía de estilo aquí