Pequeños Fragmentos de Diseño Iterativo de Componentes

♪♪ {{^}}♪♪ {{^}}♪♪ {{^}}♪♪ {{^}}♪♪ Hola a todos. Mi nombre es Daniel, y me gustan las rocas. De hecho... Es una foto mía en Islandia con alguien que coleccionó muchas rocas. No yo. Soy líder de sistemas de diseño en Personia y algo que me gusta que también es un poco nerd son las matemáticas. Me gustan las matemáticas. ¿Por qué me gusta esta cosa nerd? Es porque de alguna manera, es una ciencia muy exacta y me gusta que generalmente hay una solución óptima para todo lo que hacemos. Supongo que la ingeniería de software... Sí. Siempre hay muchas opiniones. Hay muchas maneras de resolver un problema.

Por ejemplo, digamos que queríamos construir un componente de menú desplegable como este. Una forma de construirlo en una API es hacerlo con props. Tengo los props tienen etiqueta. Esto es simple, y creo que la mayoría de los ingenieros usarán esto porque siento que a los ingenieros les gustan los props. Es muy directo. La siguiente posible manera podría ser componentes composables. Podrías tener este menú desplegable, tener estos subcomponentes y luego simplemente juntarlos. Lo que es realmente agradable es que puedes mezclarlos y combinarlos. Estoy viendo esto más a menudo en los sistemas de diseño. ¿Cuál es mejor? ¿Cuál crees que es mejor? La respuesta de un ingeniero senior sería, bueno, depende. ¿Verdad? Analicemos. Los props son realmente buenos con TypeScript. Cuando lo estoy escribiendo, es realmente agradable ver lo que está sucediendo. Necesito poner un valor aquí y luego, está bien, aparece. Puedes fácilmente, sobre la marcha, entenderlo. Por otro lado, la composición... Podrías tener otros tipos de componentes. Podrías crear otros tipos y ponerlos y aún funcionar.

Digamos que quiero envolverlo en un tooltip. Puedo hacerlo. Aún funcionará. Puedes ver que hay mucha mezcla y combinación sucediendo. Por otro lado, con los props, será un poco difícil. Terminas creando estos enormes objetos para poder obtener lo mismo. Puedes ver un poco las diferencias en el enfoque. Lo que quiero decir con esto, siempre hay pros y contras, incluso en las pequeñas cosas. También, en las cosas grandes, hay muchos pros y contras.

Si alguien sabe, este es un diseño de mampostería. Recientemente, hay una propuesta de API de CSS masonry. Esta es la discusión que está sucediendo entre Apple y Google sobre cuál es la mejor API para CSS masonry. Es solo un montón de casos límite para manejar. Incluso situaciones más grandes tienen problemas para decidir cuál es la mejor API para trabajar. Volvemos. El ingeniero de software tiene muchas respuestas. ¿Qué tipo de estrategias puedo usar como ingeniero para tomar mis propias decisiones? Una que conozco y probablemente todos ustedes conocen es esta llamada YACNI. Escuchas YACNI aquí, YACNI allá. Siempre que alguien te pregunta por qué está sucediendo esto, puedes simplemente decirles YACNI. Para aquellos que no lo saben, YACNI significa you ain't gonna need it. Simplemente construyes exactamente lo que necesitas y lo envías. Simplemente envías rápido, realmente, realmente rápido. Tu evaluación de desempeño resulta realmente excepcional. Como adivinaste, con el tiempo, esto crea deuda técnica.

Un ejemplo de usar YACNI en este componente simple que tiene un icono es ahora necesito una bandera, agrego un prop de bandera. Ahora necesito algún error y una advertencia y un color tal vez, y necesito agregar un tooltip y luego tener algún booleano para alguna situación especial para que este componente se comporte bien. Puedes ver que esto termina siendo un componente Frankenstein con el tiempo. Si haces un poco de esfuerzo y haces esto reutilizable, puede ser muy útil en términos de API. Por ejemplo, este componente podría tener un accesorio que pueda recibir banderas, iconos y otras cosas que no solo hace, y los colores podrían ser semánticos. Y podemos tener un componente tooltip reutilizable que pueda ser usado en otras áreas también.

Y luego la situación especial que quieres manejar simplemente manejándola afuera. Entonces, ¿por qué deberíamos preocuparnos por esto? En algún momento de mi carrera, estaba usando mucho YACNI y comencé a trabajar en Shopify en un proyecto de código abierto y comencé a preocuparme por las APIs que lanzaba porque se supone que deben permitir a las personas hacer las cosas que quieren hacer y si no sucede, entonces es realmente triste. Y ahora trabajo en Personio. Es lo mismo con los sistemas de diseño. Es averiguar cómo puedo hacer que la API funcione bien. El problema también es que si haces una API que no es buena, hay un costo. Es realmente difícil revertir. Tus compañeros se frustran extremadamente y te ves mal.

Así que, por ejemplo, UseEffect es un ejemplo de una API que frustra a mucha gente. Imagina intentar eliminar UseEffect de tu base de código. Eso va a ser bastante difícil. Así que puedes ver cómo una vez que creas una API a veces se queda para siempre. Entonces, ¿cómo puedo hacer buenas APIs? Me digo a mí mismo. Veamos algunas de las grandes. TC39, ellos son el grupo que realmente está creando las nuevas APIs de JavaScript. Al igual que AsyncAwait. Así que pasan por un proceso realmente grande porque quieren asegurarse de que la API sea buena. Tienen una idea, una propuesta, el borrador, tantas cosas. Lanzaron AsyncAwait y les tomó cuatro años terminar eso. No tenemos ese tiempo. Cuando estamos construyendo APIs, no vamos a simplemente esperar cuatro años. Vamos a lanzarlo. Digamos que probablemente queremos hacer APIs entre Yagni y TC39, en algún lugar intermedio. Hice mi propio proceso que llamo diseño iterativo de componentes donde trato de averiguar qué es lo suficientemente bueno para un lanzamiento antes de publicarlo. Vamos a repasarlo muy rápido. El paso uno es prototipar. Cuando Remix fue adquirido por Shopify, comenzamos a construir todos estos componentes de comercio electrónico sobre Remix. Tan pronto como comencé a usar Remix, te das cuenta de que tienen un concepto de loaders y otros conceptos que no son React normales. Básicamente sin prototipar, a veces es difícil entender cómo se puede usar la tecnología para la API que estás construyendo. Muchos ingenieros simplemente prototipan la primera cosa y la lanzan.

Y esto es, de nuevo, haciendo Yagni. Creo que puedes tener mejores APIs si sigues un proceso adecuado. Segundo paso, generalmente escribo un RFC. Lo que esto significa es algo así, esto es un RFC de tarjeta. Escribes exactamente lo que vas a hacer. Cuando haces esto, te das cuenta de qué partes de tu API suenan realmente extrañas de explicar. Y eso suele ser una señal de que algo es extraño en la forma en que estás explicando las cosas. Podrías volver y iterar aquí.

Y el paso final aquí es compartir. Es el tercer paso. Y compartir es difícil porque a veces tenemos orgullo como desarrolladores y no queremos recibir comentarios y solo queremos lanzar inmediatamente. Pero el problema de no recibir comentarios es que cuando estás trabajando con un problema, lo que sucede es que lo estás mirando tan de cerca que ya no puedes ver objetivamente. Es como cuando pintas y piensas que tu pintura se ve genial pero luego miras después y no es tan genial. Pensé que era algo así. Compartir es bueno.

Por ejemplo, el equipo de React, tenían el compilador de React, hacen lanzamientos tempranos. Comparten con todos lo que van a hacer incluso si a veces no nos gusta. Así que una vez que obtenemos suficiente confianza, es lo suficientemente bueno, iteramos en esto y luego lanzamos el componente, finalmente podemos celebrar y luego navegar hacia el atardecer. Pero espera un minuto. ¿Te ha pasado esto alguna vez al construir APIs? Alerta de spoiler. Todas las APIs, nunca hay un estado de nirvana para las APIs. Siempre hay una sensación de que algo no está bien, algo está roto aquí. Todo el tiempo que he trabajado, sentí que nunca llegamos allí y probablemente nunca lo haremos. Así que todo lo que puedes hacer es probablemente disfrutar el proceso de crear APIs. Y ese es mi consejo final. Gracias. Ese es mi enlace tres, no sé cómo se llama. Mantente en contacto. Adiós.