Usando React Sin Usar React

La fuente de esto, la inspiración para esta charla, son los casos en los que tengo que construir aplicaciones de JavaScript puro. Y cada vez que me pongo a hacer eso, siempre empiezo a pensar como un desarrollador de React. Así que lo que hice después de un tiempo, simplemente saqué algunas ideas y básicamente, esto es lo que voy a compartir con ustedes.

Así que como acaban de descubrir, soy Krassi, escribí algunos libros. Los dos primeros son basura, no los compren, ya no tienen sentido. Los otros dos, si les gusta leer, tienen algo de sentido. Así que tengo esta pequeña aplicación, que ahora ven, hay este botón. Cuando lo hago clic, voy al servidor web, obtengo algo de JSON. ¿Saben cómo pronunciar correctamente JSON? Nosotros, como profesionales, deberíamos saber cómo pronunciar JSON. Así que la pronunciación real es JASON.

Así que volvemos al servidor, obtenemos algo de JSON. Luego avanzamos para renderizar esto como un elemento select. Luego puedo elegir algunos de los shows y luego simplemente renderizo alguna información. Y ahora, si tengo que construir esto sin React, probablemente terminaré teniendo este marcado. Y ahora, cuando pienso en cómo construir esto, inmediatamente lo que empiezo a reconocer es que, bueno, podría pensar en componentes. Tengo etiquetas H1, así que pienso, está bien, esto puede ser solo un componente de título. Luego avanzo, veo la cuadrícula, así que, está bien, entonces construiré un componente de cuadrícula. Tengo elementos de cuadrícula, que ahora tengo que dividir todo en columnas. Luego llego a esta parte, que es la información para cada personaje del show.

Entonces me digo a mí mismo, está bien, simplemente crearé un componente de personaje. Y esto es básicamente lo primero. Cada vez que no estoy usando React, en realidad empiezo a pensar en componentes. Y antes de eso, porque estoy haciendo esto desde hace más de 20 años, no era así. No estaba pensando realmente con esto en mente.

Así que lo primero realmente típico de React son los componentes. Suena simple, pero esta es la verdad. React está creciendo realmente rápido, creció realmente rápido, y escala funciona realmente bien porque tenemos esta arquitectura basada en componentes. Entonces, ¿qué significa crear un componente? Bueno, cada componente tiene entrada, tiene algún tipo de lógica, como un ciclo de vida, y luego salida. Y, por supuesto, lo principal es el elemento de composición en todo esto.

Así que si tengo que construir este mismo ejemplo con componentes, podría crear simplemente funciones simples. Podría crear funciones simples que devuelvan cadenas. Podría, nuevamente, tomar prestado el concepto sobre la prop de children. Mis argumentos de las funciones son solo las props en React. Y como pueden ver aquí, simplemente estoy combinando, especialmente el último, la función de personaje está usando como esta composición realmente simple.

Sí, aquí está, por ejemplo, la función show, que utiliza las grids. Paso alguna configuración, renderizando, tres columnas. Así que es realmente, realmente posible aplicar los mismos conceptos si no estás usando React.

¿Qué pasa con JSX? Cuando llegó JSX, todos se volvieron locos diciendo, bueno, ¿qué es esta sintaxis tipo HTML en mi JavaScript? Era realmente extraño. Estaba realmente en contra. Pero estaba en contra de los hooks. Ahora estoy en contra de los componentes de servidor de React. Y sé que los adoptaré. Esta es la verdad, en realidad.

Y los adoptaré porque es una experiencia de desarrollador realmente buena. Y si quieres usar JSX y no tienes React, aún puedes hacerlo, porque JSX es solo azúcar sintáctico, ¿verdad? Cada componente de React es básicamente una llamada a la función React.createElement. Así que todo lo que tenemos que hacer es configurar nuestro Bundler, básicamente para reemplazar React.createElement con algo que definamos. Y esto es como, podría ser banana dance si quieres. Y luego obtenemos esto.

Así que sin React. Podrías escribir tu propio JSX. Podrías recibir algo de JavaScript. Y luego escribes tus propias cosas. Las cosas que vi a lo largo de los años, y esto es un poco un abuso de este tipo de patrón. Definitivamente creo que no es una buena idea. Pero vi una empresa que amaba tanto JSX que estaban escribiendo su CSS con JSX, lo cual era algo realmente extraño. Y sí.

El otro caso más válido es una empresa que usa JSX para definir su enrutamiento de Express.js, porque les gusta cómo funciona React Router. Así que querían la misma API, pero no tienen React en el servidor. Así que lo que hicieron fue básicamente comenzar a usar la herramienta de construcción ES, solo configurarla correctamente y luego escribir un poco de lógica para entender un poco la sintaxis.

¿Qué pasa con la separación de preocupaciones? Cuando comencé a usar React, todo estaba un poco en contra de eso. Porque durante años seguí la separación de preocupaciones, lo que significa que los estilos deberían estar en un lugar, la lógica debería estar en otro, la plantilla debería estar en un tercer lugar. Todo debería estar dividido, debería hacerse correctamente. Y cuando llegó React, todo está en un solo lugar. Y a lo largo de los años, me di cuenta de que la separación de preocupaciones en React todavía está ahí. Solo depende de qué tipo de componentes creemos.

Porque podrías crear componentes para el estilo, podrías crear componentes solo para la lógica. Ahora tenemos los hooks, que son puramente sobre lógica, ¿verdad? Nuestro marcado es las plantillas. Así que la separación de preocupaciones sigue siendo un concepto válido. Creo que React en realidad está ayudando en esta dirección, porque todos aprendimos que cuando estás escribiendo componentes, no puedes simplemente lanzar todo en un componente. Comienzas creando un vertedero de componentes inteligentes, luego estás extrayendo la lógica en hooks. Así que hay separación de preocupaciones, y React en realidad está ayudando en esta dirección.

Y aquí hay un ejemplo. Apuesto a que probablemente tienes algo como esto. Podrías ver estilos en la parte superior, luego tenemos algo de lógica, como una lógica asíncrona, luego tenemos la plantilla al final. Bueno, esto es realmente solo, podría ser solo esto, donde extraemos la lógica en un hook, tenemos las plantillas solo conteniendo algo de marcado, ¿verdad? Y el estilo del botón está en su propio componente.

Y cuando construyes cosas sin React, en realidad estás siguiendo este mismo patrón. Así que estás siguiendo la separación de preocupaciones, lo cual es bastante importante para tu aplicación para escalar bien. Así que es una cosa más que puedes obtener de React, es que, de hecho, estás simplemente dividiendo las cosas en diferentes áreas. El control para React.

Si vuelves a este ejemplo al principio, donde hago clic en el botón, obtengo el JSON, luego renderizo el select, luego hago clic en algunos de los elementos, y luego muestro algún contenido. Así que es básicamente de lo que está hablando esta imagen, como cosas paso a paso. Y si tengo que ordenar esto en mi cabeza, sería algo así. Realmente paso a paso cómo va el flujo. Y luego si quiero implementar esto con JavaScript puro, es solo yo usando innerHTML en un elemento.

Simplemente lanzo algún botón. Hay una función global. La ejecuto, luego voy a obtener los datos, luego renderizo. Y cuando renderizo, el elemento select tiene este controlador onChange, ¿verdad? Que dispara esta función, y renderizo de nuevo. Así que esto es lo que sucede en mi cabeza cuando todo está funcionando bien. Pero esto es realmente programación imperativa. Soy yo diciendo cómo deberían suceder las cosas y cuándo. Mientras que React es realmente declarativo. Y esta es la gran diferencia entre cómo estaba haciendo las cosas antes y cómo quiero hacer las cosas ahora.

Entonces, lo que es mejor es realmente crear, por ejemplo, un estado, ¿verdad? Esta es como la cosa principal en React, donde tienes esta fuente única a través del estado, y luego, basado en el estado, renderizas. Y si quieres cambiar algo en la pantalla, básicamente cambias el estado. Así que ahora agrego la función sobre el estado, sobre cambiar el estado. Y no olvido que después de actualizar el estado, realmente tengo que volver a renderizar. Así que hago esto ahora, y luego en mi función de renderizado, explico de manera declarativa lo que necesita suceder. Si esto está cargando, entonces muestra esto. Y todo esto no tiene nada que ver con React. Puedes ver que podría simplemente obtener esto, podría usarlo sin React.

Así que la forma declarativa de escribir y pensar no está ligada a React. Podrías realmente tomar este concepto, este patrón, usarlo en otro lugar. Y esto lleva a la misma conclusión, donde tenemos este flujo de datos unidireccional, donde tienes estado, cambio, re-renderizado, interacción del usuario, cambio del estado, y luego haces lo mismo. Así que este tipo de flujo no era realmente típico en el pasado. Cuando Angular, por ejemplo, llegó, había este enlace de datos bidireccional, que es como lo opuesto a esto. Escribes algo, tienes el estado, luego tienes la UI, y estas cosas están sincronizadas inmediatamente entre sí.

Así que cuando cambias uno, el otro se actualiza automáticamente. Cuando cambias la UI, tienes el estado actualizado automáticamente. Y esto fue hecho por el framework. Mientras que el concepto aquí en React es diferente, para que cambies algo, tienes que ir y actualizar el estado. Por eso tenemos esta entrada no controlada y controlada, ¿verdad? La idea de tener esta entrada es realmente interesante, porque la primera vez que probé React, tenía este campo de entrada, y no podía actualizar el valor del campo de entrada. Estoy escribiendo en el campo, ¿por qué no está cambiando? No está cambiando porque tenía este valor en el estado, y solo estoy pasando el valor del campo de entrada a las entradas, pero no estoy actualizando el estado con el hook.

En aquel entonces, eran los componentes de clase con set state. Luego descubrí que, bueno, esto es demasiado código solo para actualizaciones, para solo tener un campo de entrada, ¿verdad? Tienes que actualizar manualmente, luego volver a renderizar, y todo este asunto. La verdad es que a lo largo de los años, esto me hace pensar menos en lo que estoy haciendo, porque no hay magia. Sabes, la única fuente de verdad está realmente ahí. Lo único de lo que tengo que ocuparme es de la gestión de mi estado.

Así que el flujo de datos unidireccional es otro concepto que no tiene nada que ver con React. Se introduce allí, pero podrías tomar esta idea y aplicarla a otras aplicaciones. Realmente no tienes que usar solo React si quieres ir allí. Aquí estoy mostrando cómo se hace. Es básicamente el mismo código que antes. Tenemos renderizado de estado, actualizamos el estado, renderizamos de nuevo. Así que gestión del estado. La gestión del estado es algo sobre lo que podríamos hacer una masterclass completa.

Lo que quiero decir sobre la gestión del estado es que, y lo que quiero a lo largo de los años con React es que la gestión del estado no se trata de las herramientas. No se trata de si usas Redux, Recoil, o Zustank, o Context, o Hooks sobre estados. Estas son solo herramientas que te ayudan a cómo gestionar el estado. La gestión real del estado se trata de que tú descubras qué tipo de estado tienes, y dónde debe vivir este estado. Por ejemplo, digamos que tengo una capa de autorización, y tengo a mi usuario autorizado, entonces, ¿dónde está la información sobre el usuario? ¿Tiene que estar en algún componente en alguna parte, o necesita estar en la parte superior? Así que esto es básicamente la gestión del estado. Es tú decidiendo dónde vive el estado.

Y luego, basándote en esta decisión, tomas las decisiones sobre qué tipo de herramientas necesitas. A veces tienes un párrafo gigante de texto, y quieres truncar el texto, y tienes un botón de leer más. ¿Esto va a estar en un estado global? No, ¿verdad? ¿Deberíamos dejar solo un poco de gestión del estado en este componente en particular? Y de esto se trata la gestión del estado. Así que después de años trabajando con React, esto es lo que estoy obteniendo de allí. Básicamente, cuando empiezo a hablar sobre estados, realmente mi primera pregunta es, ¿dónde vive el estado? Y sí, esta imagen está ilustrando los diferentes niveles de gestión del estado.

Por supuesto, ideas como Redux, no son solo sobre React. Sabes que Redux no existe solo con React. Podrías usarlo en Angular o Vue o lo que sea. Así que es una cosa más que salió del ecosistema de React, y la gente lo está usando en todas partes. Es porque es un concepto simple. Y esta es la dirección de mi charla, que hay muchas cosas en React que podrías simplemente tomar de allí, y aplicarlas en otro contexto. Esto es algo que realmente amo de esta tecnología. Así que esto es un poco más de código, pero es una implementación simple de Redux. Apuesto a que cada uno de nosotros realmente implementó Redux por sí mismo, porque es bastante fácil. Y dices, sí, podría hacerlo yo mismo.

Es lo mismo con el Flux, que vino antes de eso. Hay tantas implementaciones, porque es simple. Es solo una idea poderosa, y es realmente simple. Así que ahora haré un poco de codificación en vivo. Y quiero mostrarte cómo, por mi experiencia, veo que la gente realmente usa React. Y al final, veremos si esto es una buena idea o no. Así que digamos que tengo un formulario. Pero como el formulario es un poco feo, quiero agregar más espacio. Y como soy un desarrollador profesional, la forma de agregar espacio es realmente agregar algunas etiquetas de salto de línea, ¿verdad? Esta es la primera herramienta a la que recurres para hacer espacio cuando eres un desarrollador profesional. OK, eso es genial. Pero como soy un senior, quiero usar algo como Tailwind. Así que empiezo a agregar un poco más de cosas. Agrego algunas clases, especialmente para el botón al final. Agrego algo así como 17 clases para hacer que este botón se vea realmente bien. Y verás en un segundo que realmente está funcionando bastante bien.

Lo que realmente no funciona es el hecho de que no puedo hacer que estos botones de radio funcionen. Porque si hago clic en uno de los botones, puedo seleccionar el otro. Así que ahora, si pienso como un desarrollador de React recién salido de un bootcamp, iré aquí y realmente comenzaré a hacer algo de gestión del estado. Así que usaré mis poderosas habilidades sobre el uso de useState. Así que agregaré los atributos checked a mi campo de entrada. Gestionaré esto con el estado, y todo es realmente, realmente hermoso. Ahora, cuando hago clic aquí y cuando hago clic aquí, todo está funcionando como se esperaba. Son como interruptores.

Pero ahora, quiero poder hacer clic en las etiquetas también. Entonces, ¿cómo solucionar eso? Bueno, haré más. Envolveré cada etiqueta con Span y ahora es otro controlador de clics. Así que podría gestionar el estado y podría seleccionar correctamente cualquiera de las opciones. Todo esto está bien, pero ¿crees que es una buena idea? ¿Verdad? No. Veo a la gente mirando, no, no, está bien. Así que este es el problema que estoy viendo hoy. Mucha gente está usando React sin darse cuenta de que un montón de cosas ya están ahí. Así que son proporcionadas por la plataforma.

Y lo primero que tenemos que arreglar... Aquí, olvidé, por supuesto, agregar un controlador de clics en el botón. Así que cuando hago clic, como que envío el formulario. El caso es que ni siquiera tengo un formulario aquí. Así que el primer paso es simplemente agregar el elemento de formulario. Porque cuando haces esto, todos los elementos dentro del elemento de formulario, comienzan a funcionar de una manera diferente. Entonces tal vez, en lugar de solo usar esto, tal vez pensaré un poco sobre accesibilidad, y comenzaré a usar un field set. Porque esto es como un agrupamiento, diferentes cosas de mi formulario. Luego, si avanzo, eliminaré toda esta tontería sobre la gestión del estado. Porque no tengo que hacerlo. Ya está ahí. Es parte de la plataforma. Todo lo que tengo que hacer es simplemente agregar un atributo name a mis campos de entrada.

Y si los atributos name son los mismos en múltiples inputs, los estamos uniendo, y puedo hacer esto. Ahora, ¿qué pasa con las etiquetas, sí y no? ¿Cómo habilitar realmente el clic en ellas?

Bueno, simplemente usaré un elemento label. Simplemente envolveré todo en label. Y ahora, realmente está funcionando.

Y no solo eso, puedo usar mis teclas de flecha para cambiar entre las opciones. Así que piensa en cómo, si solo usas React, tienes que implementar esto tú mismo. Tienes que detectar cuando el usuario está haciendo clic a la izquierda y a la derecha.

Así que sé que este es un ejemplo realmente extremo, pero créanme, sucede. La gente simplemente llega de algún lugar, comienza a usar React, y se olvida de todos los fundamentos y todas las cosas que realmente están ahí. Por supuesto, la función de envío se vuelve un poco diferente. Porque si tienes un botón en un elemento de formulario, y si omites los atributos de tipo, el valor predeterminado del tipo es enviar, y el formulario se envía inmediatamente si haces clic en el botón. Así que no tienes que hacer clic, no tienes que llamar a la función. Esto simplemente sucede porque así es como funciona el navegador. Incluso podría comenzar a escribir aquí, presionar enter, y mi formulario se envía. Entonces, ¿esto está ahí si no uso elementos de formulario? Tal vez no, no lo sé. Pero definitivamente es algo que el usuario quiere, y luego no se lo estás dando. Porque estás tratando de reimplementar cosas que se hacen con React, Way, y todas las cosas.

React es realmente genial. Mi punto, de esta presentación, la otra cosa además de obtener todo de React y usarlo afuera, es que deberíamos aprender los fundamentos. Porque por eso, y luego podremos escribir mejores códigos de React. Porque no tenemos que implementar todo. React es realmente agradable, pero no sirve al propósito de la plataforma. Así que cuando empieces a escribir React, simplemente no tomes el ascensor inmediatamente, toma las escaleras aprende las cosas paso a paso, aprende HTML, aprende CSS, aprende cómo hacerlo sin React. Y luego verás el poder de React, donde realmente brilla y por qué nos ayuda a construir grandes aplicaciones web.

Así que sí, esto es lo que tengo para ustedes. Gracias. Espero que haya sido útil. Bien, vamos a ello. Me encanta lo que dijiste, cómo terminaste con el aprendizaje de los fundamentos. Creo que es muy fácil para la gente saltar directamente a un framework y no entender por qué el framework tomó ciertas decisiones. ¿Cómo crees que la gente puede ir y encontrar eso? Especialmente porque muchos tutoriales los llevan directamente a React, los llevan directamente a estos frameworks. ¿Cómo crees que la gente debería proceder para encontrar la historia detrás de lo que estos frameworks resuelven? Sí, creo que la mejor manera de hacerlo es simplemente encontrar un mentor, probablemente. Porque hoy en día tenemos tantos recursos y el contenido está en todas partes y es realmente difícil filtrar lo que llamamos fundamentos. Así que creo que la mejor manera de hacerlo es simplemente encontrar a alguien que tenga más experiencia que tú, y básicamente le preguntas, oye, hombre, ¿cuál es la base de los formularios HTML? ¿Qué tengo que aprender? En la mayoría de los casos, te remitirán a la documentación, la documentación de MDN y lugares como este, donde la gente pasa años trabajando en estas cosas y explican las cosas realmente bien. Pero creo que la forma más rápida es simplemente encontrar a alguien.

Bien, bien, bien. Bueno, ese es un buen consejo. Ups, marqué la pregunta como marcada, déjame traerla de vuelta. Así que a menudo cuando estamos resolviendo problemas, vemos patrones similares y tal vez otras personas también están resolviendo problemas similares, por lo que las soluciones se ven similares. Y esta pregunta va por ese camino, que es, ¿no estás construyendo una mezcla de Redux y Signals? Cuando lo miras filosóficamente, ¿estás de acuerdo? Tal vez lo estás pensando de manera diferente. La pregunta es si... ¿No estás construyendo una mezcla de Redux y Signals?

Bueno, creo que muy a menudo estas ideas, estos patrones... Y esto es cierto para los frameworks en general, cómo la gente realmente elige frameworks. Y eligen frameworks no porque sean de alto rendimiento o tengan una gran comunidad o lo que sea. En la mayoría de los casos, eligen un framework porque les gustan las ideas, pero de alguna manera se alinean con la filosofía de este framework. Y es lo mismo con estas bibliotecas y herramientas de gestión de estado y todo. Si simplemente no te gusta cómo funciona, es difícil adoptarlo. Así que sí, por ejemplo, no tengo experiencia con Signals. Estoy un poco como, sí, veamos cómo va, a dónde va.

Mientras que con Redux, me decidí muy rápidamente porque era una idea realmente simple y en mi cabeza, todo debería ser realmente simple. Y se alinea con lo que estoy pensando, así que lo elegí muy rápidamente. Así que sí. Bien. Dame un momento. Y déjame volver rápidamente a nuestras preguntas. Que es, tenemos otra. ¿Cómo escalan estos conceptos en términos más amplios? ¿No se convierte esto eventualmente en otro framework de JavaScript? Esta es una muy buena pregunta. Creo que hay un equilibrio que debes encontrar básicamente porque muy a menudo cuando estoy construyendo aplicaciones vanilla, obtengo estos conceptos, empiezo a usarlos. Y de hecho, se siente como si estuvieras construyendo tu propio React muy lentamente, pero estás llegando allí. Más caminos llevan a React. Sí, exactamente. Así que el punto es que deberías obtener lo bueno, pero siempre deberías estar pensando en no ir demasiado lejos. Y esto se trata principalmente de abstraer cosas. Comienzas a crear estas grandes abstracciones y después de algún tiempo obtienes la sensación de este tipo de buen sentimiento de que, bueno, esto es tal vez demasiado. Y luego te detienes y encuentras el equilibrio.

Pero definitivamente es un buen punto y probablemente sea el mayor problema de este enfoque, de escribir aplicaciones vanilla y aplicar lo que sabes. Eso tiene mucho sentido.

Y luego la última es, ¿qué pasa con los mensajes de error que aparecen instantáneamente? ¿Cuáles son los límites de los enfoques nativos y cómo sortearlos? ¿Sobre instantáneo? ¿Qué? ¿Qué pasa con los mensajes de error que aparecen instantáneamente? Entonces, ¿cuáles son los límites de usar enfoques nativos? Porque obviamente hay muchas cosas nativas, pero funcionan de manera diferente a como los frameworks tal vez se construyen alrededor.

Respondería con, sí, depende de tu base de usuarios, supongo. Hay diferentes enfoques para manejar esto, pero realmente depende del caso de uso. Y en cuanto a tecnología, tu equipo, lo que es capaz de hacer, los usuarios, así que es un tema realmente complicado. Sí, es... Bueno, estoy 4 de 4 y depende de nuestros ponentes en preguntas y respuestas, así que gracias. Recuerden, si quieren hacer más preguntas de seguimiento, también tenemos tiempo abajo en el Q&A en vivo de los ponentes. Tenemos un poco más de tiempo para algunas preguntas rápidas.