El componente de React más caro del mundo y cómo dejar de escribirlo

Hola a todos mis amigos en React Advanced, muchas gracias por asistir a esta charla. Hoy vamos a hablar sobre los componentes caros de React, pero probablemente no del tipo de caro al que estás acostumbrado a escuchar o pensar. Vamos a hablar sobre el diseño costoso de API, específicamente un solo componente que creo que probablemente nos ha costado miles de millones de dólares como industria y por lo tanto es el componente más caro que he visto. Quiero mostrarte cómo puedes dejar de hacer ese componente en tus equipos y en tus comunidades.

Los próximos 19 minutos, esto es lo que va a parecer esta charla. Vamos a hablar un poco sobre mí, quién soy, por qué estoy aquí. Voy a compartir contigo una de mis historias favoritas, y después de eso, veremos algo de código e intentaremos sacar algunas conclusiones de la relación de la historia con el código.

Primero que nada, ¿quién soy? Mi nombre es Michael Chan. Me puedes llamar por cualquier parte de eso, Michael, Chan, Chan. Michael Chan, lo que quieras, con lo que te sientas cómodo. Me conocen como Chantastic en la mayoría de los lugares de internet que te podrían interesar como desarrollador. He pasado los últimos cuatro años como arquitecto de front-end y los últimos 12 años en algún tipo de rol de infraestructura de diseño. Así que estoy realmente apasionado por el diseño y el diseño de componentes. He presentado el show Podcast de React. Así que si estás escuchando mi voz, pero suena más lenta porque no está en 2X, ese 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 viene. Estoy construyendo una comunidad, una comunidad de Discord. Puedes encontrarla en Chan.Dev.Discord, donde hacemos muchas cosas durante el almuerzo. Muchas actividades basadas en el almuerzo para que podamos 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 UX de la web. Quería invitarte, si estás interesado en trabajar conmigo y con el equipo allí, visita chan.dev.chromatic. Y eso te llevará al lugar correcto.

Ahora, quiero compartir un último enlace contigo antes de seguir adelante. Eso es chan.dev.expensive. Allí, encontrarás cualquier cosa relacionada con esta charla, ya sean enlaces o notas o esta misma presentación. Y después de que esto 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, hace tres años o así, 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é realmente no funcionaban, patterns que pensé que no funcionaban bien en aplicaciones complejas.

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

Y mientras hice el trabajo hace varios años para entender dónde estaba en mi career, ese trabajo está sucediendo a diferentes ritmos para diferentes personas, y puede hacer que sea realmente difícil coordinar. Ahora que hemos establecido eso, quiero contarte una historia que realmente cambió la forma en que pienso sobre cómo tomamos decisiones en code. Y me está dando un ejemplo divertido en mi cabeza para pensar, y solo quiero compartir eso contigo. Así que vamos a sumergirnos.

Ahora la historia es este libro llamado La Dama Que Puso Sal en Su Café. Ahora es muy antiguo, y desafortunadamente, mientras lo leía de nuevo, es muy distractingly gendered, lo que me hace sentir incómodo compartiéndolo. Um, con eso, y la esperanza de que no viole e incorpore leyes de derecho en esta charla, decidí que daría una versión abreviada e interpretada de la historia, utilizando emojis de gatos y gatitos. Así que he titulado esto el gato personificado que puso sal en su café.

Así que la historia va así. Hay un gato, y es la mañana y este gato hace una taza de café. Ahora, justo cuando va a poner un poco de crema en este café 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 vestir tu taza de café. Ahora, afortunadamente, tenía todos sus gatitos alrededor, y todos se reúnen para tratar de averiguar qué se puede hacer para salvar esta taza de café que ahora tiene sal dentro de ella. Ahora, había un niño 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. Entonces, deberíamos consultar a un químico. Y por supuesto, el niño había ido a la universidad, y todos asumieron que era muy inteligente. Entonces, acordaron que primero deberían consultar a un químico. Entonces, salen al químico que conocen, encuentran al químico, y hay una cosa que deberías saber sobre este químico. Este químico no es un buen químico. 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 con. Primero, 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, te daremos el oro para averiguar cómo podemos salvar esta taza de café. Por supuesto, el químico estaba dentro. Así que el químico comienza a aplicar toda su ciencia y química

Desafortunadamente, esto resultó en una taza de café que era nauseabunda para todos los gatos y los gatitos. Entonces, ya no sabía a sal, pero también era extremadamente asqueroso. Por supuesto, el arrogante herbólogo culpó al café, diciendo que estaba embrujado y se fue a compartir sus buenas noticias con otros que estaban menos malditos.

Ahora, esto dejó a los gatitos en un poco de apuro. Estaban al final de su ingenio y el gato se estaba poniendo irritable porque era bastante tarde en el día y aún no había tomado su café. Ahora, en este punto, se reunieron por tercera vez para ver cuál podría ser el próximo paso posible. Esta vez el gatito universitario se sentía mucho más tranquilo y modesto, dando espacio para que los otros dos gatitos hicieran sus suggestions. Y lo que sugieren es consultar con el sabio y experimentado vecino de al lado. Entonces lo hacen. Y la respuesta de este sabio y experimentado vecino es simplemente preguntar, ¿no puedes 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 deleite. ¿Por qué no pensamos en eso? Gritaron. Hicieron una nueva taza de café y el gato estaba feliz.

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

Bueno, vamos a saltar a algo de code. Ahora quiero mostrarles 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 voy a mostrárselo ahora. Ahora es posible que lo hayan visto porque existe exactamente en la página principal de los docs de ReactJS.org. Ahora quiero mostrarles esto en la práctica. Quiero decirles no solo que es el componente más caro, sino mostrarles algunas de las razones por las que creo que lo es. Y pasar por este proceso con ustedes.

Así que lo he puesto dentro de una base de code tal como está, pero usando hooks porque ¿por qué la página principal de React.js todavía tiene clases en ella? 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 estoy seguro de por qué. Si miramos este componente vemos que es un div, así que eso es desafortunado. Va a fallar cada vez que intentemos poner puntuación fuera de ese componente. Así que solo necesitamos agregar algunas nuevas props con el valor por defecto. Lo hacemos. Elegimos la puntuación final como el nombre de la prop porque hemos sido profundamente heridos por cosas que son demasiado genéricas antes. Sabemos que puede haber algunas otras preguntas de puntuación más tarde. Así que esto se ve bien. Lo hacemos commit y todos están felices. Tuvimos otra alerta del equipo de UX. Oye, aquí de nuevo el equipo de UX. Gran trabajo en la última característica. Los equipos ya han estado usando la puntuación final. Yada yada yada.

Nos gustaría personalizar aún más el mensaje con saludos lindos como yo hola qué tal. Sabes, cosas de ese tipo. ¿Puedes ayudarnos? Bueno, sí, de hecho. Podemos repetir el mismo proceso que hicimos antes utilizando una nueva prop con un valor por defecto. Así que algo así. Simplemente moveremos lo que teníamos estáticamente allí. Lo subimos como un valor por defecto. Tenemos una prop para ello. Podemos cambiar eso y aquí vamos. Fácil y sencillo.

Recibimos otra solicitud. Nuestro equipo de marketing está creando vídeos y los revisores de contenido están preocupados por la puntuación del saludo en el tablero de mandos. En lugar de hey Joan debería tener una coma. ¿Es esto algo que podemos arreglar fácilmente? Sí, y de hecho, debido a la forma en que hicimos el saludo y es sólo una coincidencia, pero puedes arreglar esto por tu cuenta, simplemente pon una coma allí. Genial, ni siquiera tengo que hacer nada con esto. Comprobado, así que esto es interesante.

Estamos colaborando con UX en un proyecto de Bonanza de Cumpleaños. Nuestro objetivo es una animación de globos de cumpleaños única sobre el nombre del usuario. Doy un pequeño ejemplo aquí, pero utiliza un nombre de clase. No voy a leer todo. Sólo necesitamos aplicar un nombre de clase, eso está bien. Así que vamos a nuestro code, debería ser bastante simple. De hecho, hay un patrón muy conocido para esto. Es el uso de las propiedades de descanso de objetos para sacar todos los atributos y luego usar JSX para ponerlos en el elemento DOM. Así que hacemos eso, bastante simple. Ahora tenemos otra solicitud y esto es bastante 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 tener algunas frutas bajas que podríamos aprovechar cambiando el marcado html para que sea más semántico. Así que hay una pregunta de cómo podemos arreglar esto ahora que ya tenemos un componente que sólo hace un div. Bueno, en realidad podemos hacer esto de una manera no destructiva con algo que es

Ahora finalmente con esta solicitud de internationalization sabes que es hora de que empecemos a pensar en derecha a izquierda y así tenemos esta nueva función que podemos usar y podemos simplemente usar en lugar de tener nuestro propio saludo, ahora podemos procesar eso simplemente dando 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 patterns que usamos como desarrolladores de React ya sea delegación prop de componente poli o polimórfica as si te gusta llamarlo así, valores por defecto, asignación de desestructuración todas estas cosas realmente geniales para hacer un componente extremadamente flexible y reutilizable. Pero me quedo aquí preguntándome si no estamos haciendo lo que los gatos y los gatitos hicieron para desalar su taza de café salada. Y si no nos satisface, porque no estamos siguiendo los pasos del gato colegiado para sentirnos elegantes en la búsqueda de todas estas cosas que nos hacen sentir conocedores. Infundiéndolo con una nueva química o hierbas. Cuando podríamos haber tomado el camino de preguntar a nuestro sabio y conocedor vecino, quien podría haber sugerido que en ningún momento todo esto fue necesario. Que elegir usar un componente y props en realidad nos puso en un camino donde nos vimos obligados a resolver algunas de estas cosas que en realidad no necesitaban ser resueltas. Porque todo este tiempo habíamos tenido estas herramientas disponibles para nosotros y estábamos simplemente recreando en nuestros propios términos cosas que teníamos disponibles en javascript y html. No necesitábamos un componente y no necesitábamos props, solo necesitábamos una función y un marcado. Ahora tengo menos de tres minutos, tengo como un minuto y medio para terminar para tratar de sacar algunas conclusiones de esto. Mi objetivo realmente no es decirte cómo code sino lanzar un error. Quiero lanzar el aire de que esto en realidad no es el Hola Mundo de React. Hay un paso por debajo de eso que nos perdimos al saltar directamente a componentes y props y que ir directamente a este paso como el primer paso para entender React y el componente de React nos ha costado como industria mucho dinero y que cada patrón que tenemos para props en realidad existe como un medio para subvertir el uso de props de esta manera histérica hacia atrás. Y mientras he hablado con la gente sobre Y mientras he hablado con la gente sobre por qué ocurre esto, he aprendido que es realmente difícil para nosotros lanzar estos errores por una serie de razones, y las razones por las que no los lanzamos suenan así. Solo estoy haciendo lo que me dice el linter. Es más seguro de esa manera. Refactorizar es una forma aceptable de procrastinación. Demostrar el dominio de los patterns demuestra que soy competente. El líder técnico, leyó un blog sobre un patrón y no se fusionará sin él. La mayoría de la complejidad genera más complejidad me hace sentir más inteligente. Las soluciones rápidas son recompensadas.

Las soluciones lentas no lo son. No me pagan más por colaborar. La energía requerida para reformular el alcance de un problema es mucha más energía de la que se necesita para implementar un parche. Soy un ingeniero, no un gerente. Si puedo, si puedo solucionarlo, no importa cuán chapucero sea, ¿por qué no lo haría? Intenta con dogma y los criterios bajan pero no suben. El problema no es el code. Es la comunicación. Queremos que la gente nos vea como gatitos inteligentes. El auge del componente nos ha obligado a acercarnos más de lo que nunca antes lo habíamos hecho. Y hay una inmensa tensión organizacional, cultural y social que conduce directamente al dolor que experimentamos al trabajar con 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 mientras lo pienso, los únicos que realmente ganan con todo esto son los consultores y educadores. Así que necesitamos mejorar en hacer la pregunta, ¿es el trabajo que estamos haciendo el trabajo que necesita 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 los children y las funciones? Los bloques de construcción básicos que siempre han existido desde HTML y JavaScript. Ahora, solo si podemos hacer eso, podemos dejar de hacer y rehacer el componente de React más caro del mundo. Hey, muchas gracias por escuchar. De nuevo, soy Chantastic, y espero que esta charla te ayude a pensar un poco mejor sobre el trabajo que estás haciendo. Paz.