El Componente de React más Caro del Mundo y Cómo Dejar de Escribirlo

En los próximos 19 minutos, esto es lo que vamos a ver en esta charla. Vamos a hablar un poco sobre mí, quién soy y por qué estoy aquí. Voy a compartir contigo una de mis historias favoritas y después de eso, vamos a ver algo de código y tratar de sacar conclusiones de la relación entre la historia y el código.

Lo primero es lo primero, ¿quién soy yo? Mi nombre es Michael Chan. Puedes llamarme Michael, Chan, Chan. Michael Chan, como prefieras, como te sientas cómodo. En la mayoría de los lugares de internet que te interesan como desarrollador, me conocen como Chantastic. He pasado los últimos cuatro años como arquitecto de front-end y los últimos 12 años en algún rol de infraestructura de design. Por eso me apasiona tanto el design y el design de componentes. He sido el anfitrión del programa React Podcast. Así que si estás escuchando mi voz, pero suena más lenta porque no está en 2X, soy yo. También he pasado el último año y medio trabajando con el Grupo de Trabajo de React. para ayudar a cerrar la brecha entre React 17 y React 18 que se avecina. Estoy construyendo una community, una comunidad en Discord. Puedes encontrarla en Chan.Dev.Discord, donde hacemos muchas cosas durante el almuerzo. Muchas actividades basadas en el almuerzo para aprender unos de otros y aprender nuevas tecnologías. Y finalmente, recientemente me uní al equipo de Chromatic, la empresa que hace Storybook. Nuestro objetivo es mejorar la experiencia de usuario en la web. Quiero invitarte, si estás interesado en trabajar conmigo y el equipo allí, a visitar chan.dev.chromatic. Y eso te llevará al lugar correcto.

Ahora, quiero compartir un último enlace contigo antes de continuar. Es chan.dev.expensive. Allí encontrarás todo lo relacionado con esta charla, ya sean enlaces o notas o esta misma presentación. Y después de que se publique, presumiblemente un enlace al video de YouTube. Ahora, ¿por qué estoy aquí? Bueno, es una pregunta interesante que comienza hace unos años. Di esta charla hace mucho tiempo, unos tres años más o menos, llamada Hot Garbage Clean Code is Dead. Si te gusta esta charla, probablemente te encantará esa.

Si no te gusta esta charla, odiarás esa. Fue un viaje realmente interesante porque comenzó más como una presentación técnica de cosas que pensé que realmente no funcionaban, patrones que pensé que no funcionaban bien en aplicaciones complejas.

Sin embargo, lentamente comenzó a tomar forma como un viaje personal a medida que aprendía mi propio sentido de pertenencia y superaba el síndrome del impostor y simplemente hacía el trabajo para superar mis demonios. Pero sentí que había algo que quedaba sin decir, específicamente sobre el costo de la coordinación, porque la coordinación es costosa.

Y aunque hice el trabajo hace varios años para entender dónde estaba en mi carrera, ese trabajo está sucediendo a diferentes ritmos para diferentes personas, y puede dificultar mucho la coordinación. Ahora que hemos establecido eso, quiero contarte una historia que realmente cambió la forma en que pienso sobre cómo tomamos decisiones en el código. Y me da un ejemplo divertido en mi cabeza para pensar, y solo quiero compartirlo contigo. Así que vamos a sumergirnos.

Ahora, la historia es este libro llamado La Dama que Puso Sal en su Café. Es muy antiguo y, desafortunadamente, al leerlo nuevamente, está muy marcado por el género, lo que me hace sentir incómodo compartirlo. Con esa esperanza de no violar y cumplir las leyes en esta charla, decidí dar una versión abreviada e interpretada de la historia, usando emojis de gatos y gatitos. Así que he titulado esto el gato personificado que puso sal en su café.

La historia es así. Hay un gato y es por la mañana y este gato hace una taza de café. Ahora, está a punto de ponerle un poco de crema a este café cuando se da cuenta de que en lugar de azúcar, ha puesto sal en el café. Y la sal definitivamente no es azúcar cuando se trata de adornar tu taza de café. Afortunadamente, tenía a todos sus gatitos alrededor, y todos se reúnen y tratan de averiguar qué se puede hacer para salvar esta taza de café que ahora tiene sal dentro. Ahora, había un gatito que había ido a la universidad y se sentía muy inteligente y dijo: 'Sabes, fui a la universidad, soy un gatito muy inteligente, y el café es solo química. Así que deberíamos consultar a un químico'. Y, por supuesto, el gatito había ido a la universidad, y todos asumieron que era muy inteligente. Entonces, acordaron que primero deberían consultar a un químico. Así que van al químico que conocen, encuentran al químico y hay una cosa que debes saber sobre este químico. Este químico no es un químico muy bueno. Han dedicado la mayor parte de su vida a la búsqueda de convertir objetos en oro, una búsqueda en la que han fracasado dramáticamente, y en este mismo momento, están tratando de encontrar formas de encontrar más oro para realizar experimentos. Al principio, el químico dice: 'No tengo tiempo para esto. Estoy muy ocupado con mi trabajo'. Pero los gatos son gatos muy aristocráticos y tienen mucho oro. Él dice: 'Bueno, les daremos el oro para descubrir cómo podemos salvar esta taza de café'. Por supuesto, el químico acepta. Así que el químico comienza a aplicar toda su ciencia y química.

Desafortunadamente, esto resultó en una taza de café que era simplemente nauseabunda para todos los gatos y los gatitos. Así que ya no sabía a sal, pero también era extremadamente repugnante. Por supuesto, el herbolario arrogante culpó al café, diciendo que estaba embrujado y siguió compartiendo sus buenas noticias con otros que estaban menos malditos.

Ahora, esto dejó a los gatitos en un pequeño aprieto. Estaban al final de sus recursos y el gato se estaba poniendo de mal humor porque ya era bastante tarde en el día y aún no había tomado su café. En este punto, se vuelven a reunir por tercera vez para ver cuál podría ser el siguiente paso posible. Esta vez, el gatito universitario se siente mucho más tranquilo y modesto, dejando espacio para que los otros dos gatitos hagan sus sugerencias. Y lo que sugieren es consultar al sabio y experimentado vecino de al lado. Así que lo hacen. Y la respuesta de este sabio y experimentado vecino es simplemente preguntar, ¿no pueden hacer otra taza de café? Ahora, esta fue una sugerencia extremadamente profunda para todos estos gatitos que habían estado buscando todo el día una forma mucho más complicada de salvar esta taza de café. Y responden con alegría. ¿Por qué no se nos ocurrió eso? exclamaron. Hicieron una nueva taza de café y el gato estaba feliz.

El fin. Ahora sé que estamos... estoy en este lado de la pantalla, probablemente estamos a un océano de distancia, pero puedo sentir tu juicio sobre esta historia y posiblemente la forma en que ha terminado. Sabes, porque es, ya sabes, completamente irrealista, ¿verdad? Nadie es tan tonto como para no darse cuenta de que se arregla el café con sal simplemente haciendo otra taza.

Bueno, vamos a ver algo de código. Ahora quiero mostrarte el componente de mil millones de dólares. El componente que he llegado a creer que es el más caro y definitivamente, desproporcionadamente caro que he visto. Así que te lo voy a mostrar ahora. Es posible que ya lo hayas visto porque se encuentra exactamente en la página principal de la documentación de ReactJS.org. Ahora quiero mostrarte esto en la práctica. No solo quiero decirte que es el componente más caro, sino mostrarte algunas de las razones por las que creo que lo es. Y recorrer este proceso contigo.

He colocado esto dentro de una base de código tal cual, pero usando hooks porque ¿por qué la página principal de React.js todavía tiene clases? Así que nuestra historia comienza con esta solicitud. Oye, nos gustaría mejorar el factor amigable de nuestros saludos con puntuación personalizada. Nuestro equipo intentó simplemente agregar puntuación pero falló. Así que no estamos seguros por qué. Si observamos este componente, vemos que es un div, lo cual es desafortunado. Fallará cada vez que intentemos poner puntuación fuera de ese componente. Así que solo necesitamos agregar algunas nuevas props con los valores predeterminados. Lo hacemos. Elegimos 'trailingPunctuation' como el nombre de la prop porque hemos sido profundamente heridos por cosas demasiado genéricas antes. Sabemos que puede haber algunas otras preguntas sobre puntuación más adelante. Así que esto se ve bien. Lo confirmamos y todos están contentos. Recibimos otra alerta del equipo de UX. Oye, equipo de UX aquí de nuevo. Buen trabajo en la última función. Los equipos ya han estado usando 'trailingPunctuation'. Yada yada yada.

Nos gustaría personalizar aún más el mensaje con saludos adorables como hola, qué tal, qué hay de nuevo. Cosas de ese tipo. ¿Nos puedes ayudar? Bueno, sí, de hecho. Podemos repetir el mismo proceso que hicimos antes utilizando una nueva prop con un valor predeterminado. Así se vería algo como esto. Simplemente moveremos lo que teníamos estáticamente allí. Mover eso como un valor predeterminado. Tener una prop para eso. Podemos cambiar eso y aquí vamos. Muy fácil.

Recibimos otra solicitud. Nuestro equipo de marketing está creando videos y los revisores de contenido están preocupados por la puntuación del saludo en el panel de control. En lugar de `hola Joan`, debería tener una coma. ¿Es algo que podemos arreglar fácilmente? Sí, y de hecho, debido a la forma en que hicimos el saludo y es solo una especie de coincidencia, pero puedes arreglar esto por tu cuenta, solo pon una coma allí. Genial, ni siquiera tienes que hacer nada con esto. Marcado como completado, así que este es interesante.

Estamos colaborando con UX en un proyecto de Cumpleaños Bonanza. Nuestro objetivo es una animación de globos de cumpleaños única sobre el nombre del usuario. Aquí hay un pequeño ejemplo, pero utiliza un nombre de clase. No voy a leer todo. Solo necesitamos aplicar un nombre de clase, eso está bien. Así que vamos a nuestro código, debería ser bastante simple. De hecho, hay un patrón muy conocido para esto. Se trata de usar propiedades de objeto rest para extraer todos los atributos y luego usar JSX spread para colocarlos en el elemento DOM. Así que hacemos eso, bastante simple. Ahora tenemos otra solicitud y esto es interesante. Podríamos haber sospechado que esto es algo que la gente querría hacer eventualmente. Pero en nuestras pruebas de accessibility nos dimos cuenta de que podríamos aprovechar algunas oportunidades fáciles al cambiar la estructura html para que sea más semántica. Entonces surge la pregunta de cómo podemos solucionar esto ahora que ya tenemos un componente que solo hace un div. Bueno, en realidad podemos hacer esto de una manera que no rompa nada con algo que es

Finalmente, con esta solicitud de internacionalización, ya es hora de que empecemos a pensar en la escritura de derecha a izquierda, así que tenemos esta nueva función que podemos usar y podemos simplemente usarla en lugar de tener nuestro propio saludo, ahora podemos procesarlo simplemente dándole el nombre a esta función y luego proporcionará el mensaje que necesitamos. Y así es como se ve nuestro componente al final del día después de agotar tantos de los patrones que usamos como desarrolladores de React, ya sea delegación prop de componente poli o polimórfica, como te guste llamarla, destructuring assignment todas estas cosas realmente geniales para hacer un componente extremadamente flexible y reutilizable. Pero me pregunto si no estamos haciendo lo mismo que los gatos y los gatitos hicieron para desalar su taza de café con sal. Y si no nos satisface porque no estamos siguiendo los pasos del gato universitario para simplemente sentirnos elegantes persiguiendo todas estas cosas que nos hacen sentir conocedores. Infundiéndolo con algo de química o hierbas nuevas. Cuando podríamos haber recurrido a nuestro sabio y conocedor vecino, quien podría haber sugerido que en ningún momento todo esto era necesario. Que elegir usar un componente y props en realidad nos puso en un camino donde nos vimos obligados a resolver algunas cosas que en realidad no necesitaban ser resueltas. Porque todo este tiempo en realidad teníamos estas herramientas disponibles y simplemente estábamos recreando en nuestros propios términos cosas que teníamos disponibles en javascript y html. No necesitábamos un componente ni props, solo necesitábamos una función y marcado. Ahora me quedan menos de tres minutos, tengo como un minuto y medio para terminar y tratar de sacar algunas conclusiones de esto. Mi objetivo no es realmente enseñarte cómo programar, sino lanzar un error. Quiero lanzar el error de que esto no es realmente el Hola Mundo de React. Hay un paso por debajo de eso que nos perdimos al saltar directamente a componentes y props y eso ir directamente a este paso como el primer paso para comprender React y los componentes de React nos ha costado a la industria mucho dinero y que cada patrón que tenemos para props en realidad existe como un medio para evitar el uso de props de esta manera histérica y retrograda. Y al hablar con la gente sobre Y al hablar con la gente sobre por qué sucede esto, he aprendido que nos resulta muy difícil lanzar estos errores por varias razones, y las razones por las que no los lanzamos suenan así. Solo estoy haciendo lo que el linter me dice. Es más seguro de esa manera. Refactorizar es una forma aceptable de procrastinación. Demostrar dominio de los patrones demuestra que soy competente. El líder técnico leyó un blog sobre un patrón y no lo fusionará sin él. La complejidad hace que me sienta más inteligente. Se premian las soluciones rápidas.

Las soluciones lentas no lo son. No me pagan más por colaborar. La energía requerida para replantear el alcance de un problema es mucha más que la necesaria para aplicar un parche. Soy un ingeniero, no un gerente. Si puedo solucionarlo, sin importar lo chapucero que sea, ¿por qué no lo haría? Prueba el dogma y los criterios se reducen, pero no aumentan. El problema no es el código. Es la comunicación. Queremos que la gente nos vea como gatitos inteligentes. El surgimiento del componente nos ha obligado a acercarnos más de lo que nunca lo hemos hecho antes. Y hay una inmensa tensión organizativa, cultural y social que conduce directamente al dolor que experimentamos al trabajar y diseñar componentes. Y creo que este problema te está costando a ti, me está costando a mí, y está costando a las empresas para las que trabajamos y a las comunidades que apoyamos. Y al pensarlo, las únicas personas que realmente se benefician de todo esto son los consultores y educadores. Así que necesitamos mejorar en hacer la pregunta, ¿es el trabajo que estamos haciendo el trabajo que debe hacerse? Y específicamente para nosotros, los desarrolladores de React, ¿son las props y los componentes la herramienta correcta para el trabajo que tengo cuando existen children y funciones? Los bloques de construcción básicos que siempre han existido en HTML y JavaScript. Ahora, solo si podemos hacer eso, podemos dejar de crear y recrear el componente de React más costoso del mundo. ¡Gracias por escuchar! Nuevamente, soy Chantastic, y espero que esta charla te ayude a pensar un poco mejor sobre el trabajo que estás haciendo. Paz.