De la teoría a la práctica: aprovechando TypeScript para una implementación exitosa de Atomic Design

Compresibilidad, número uno, es eficiencia versus legibilidad. Cuanto más optimices para la eficiencia, más abstracto se vuelve tu código y hay un límite donde la legibilidad no es buena. Ahora, todos saben eso. Sin embargo, ¿cómo percibes cuando se cruza la línea? Eso es más difícil. Flexibilidad versus eficiencia. Cuanto más eficiente eres, más tu código termina siendo super consistente, lo cual es genial. Sin embargo, hay un límite donde no es genial porque luego, si quieres hacer cambios, se vuelve problemático porque básicamente todo se derrumba. La flexibilidad sufre. Nuevamente, eso es algo que puede sonar, sí, está bien, eso es justo, pero ¿cómo percibes cuando se cruza la línea? Eso es más difícil. Y luego todo se vuelve en contra eventualmente en algún momento, porque entonces tu código es consistente porque es eficiente, pero luego tienes que agregar excepciones a medida que avanzas porque necesitas algo de espacio para la flexibilidad, y las excepciones están bien hasta que son demasiado numerosas para ser excepciones. Y luego todo sufre. Eficiencia, legibilidad, flexibilidad, todo. Entonces, nuevamente, ¿cuándo percibes que se cruza la línea? Ahora, me han dicho, sabes, si planificas con anticipación, no será un problema. Eso solo es cierto si esperas que tu producto nunca evolucione, lo cual es poco probable. Y en mi opinión, la mejor manera de avanzar y codificar un producto es no planificar, es crear un repositorio separado y cortar algo sobre la marcha, y esto es cómo llegas a experimentar las sutilezas de antemano, porque luego cuando planificas, no lo haces con la cabeza fría. Planificas sabiendo exactamente todas las sutilezas, porque has pasado por la codificación por separado y has llegado a comprender dónde algo puede ser un problema eventualmente. Entonces eso es mucho mejor en mi opinión que simplemente planificar. Solo experimenta, pasa un fin de semana codificando algo

Entonces, los fundamentos del diseño atómico, en realidad, se trata de hacerte pensar de manera rigurosa y científica. Y cuando miras una página, es un poco como si fueras un productor de música. Cuando escuchas una canción, no solo escuchas lo que los consumidores escuchan. Escuchas todas las diferentes capas de la música, cómo se creó el sonido, desde la cosa más pequeña. Reconoces un pequeño tambor. Reconoces un pequeño patrón. No ves la música como un todo.

Y supongo que para los desarrolladores front-end, supongo que debería ser de la misma manera, al menos en la filosofía del diseño atómico. Cuando estás mirando una aplicación o cuando estás usando tú mismo un producto, es una nueva forma de pensar. No piensas en términos de páginas, por ejemplo. Detectas y organizas automáticamente los patrones en tu cabeza y visualizas cómo debería ser el código. Notas primero los componentes más pequeños. Combina los componentes en componentes más grandes de manera progresiva hasta obtener una página. No comienzas con una página y trabajas hacia abajo. Básicamente, haces las cosas como con Lego. Entonces, una vez más, este es un ejemplo para que veas, cuando miro estas dos páginas aquí, noto primero el hecho de que, okay, hay una imagen y hay un reproductor de mp3. Estas son las variables. Esto es lo que cambia. Luego todo lo demás es igual. Veo que el sistema de etiquetas es exactamente el mismo. Las tarjetas son las mismas. Los títulos son los mismos. Entonces, aquí en mi cabeza, ya puedo visualizar el código. Hay una variable que cambia, el tipo de activos. Hay pequeñas cosas que se juntan como las etiquetas, la sombra en la tarjeta, el título, las pequeñas flechas, ya sabes, todas estas cosas, y también tienes constantes. Todas esas siempre son las mismas.

Nuevamente, para educar tu vista, te invitaría, como ejercicio, a mirar el storybook de Airbnb o cualquier otra empresa que veas que tiene un storybook y simplemente obtener inspiración de lo que pueden ser esas pequeñas cosas que puedes estar pasando por alto cuando revisas Airbnb. Cuando ves un pequeño esqueleto como este, por ejemplo, cuando la página se está cargando, entiendes en qué archivo se encuentra en su base de código y qué hace exactamente y las diferentes variaciones. Esto es genial para que básicamente sigas el mismo camino.

Nuevamente, TypeScript, también iré rápido en eso. Solo quería hacer una diapositiva sobre por qué algunos desarrolladores son escépticos porque creo que es importante tener empatía cuando trabajas con un colega que aún puede ser escéptico acerca de TypeScript para comprender para que cuando intentes explicarles por qué es bueno, entiendas sus puntos débiles. Visualmente, los códigos simples pueden parecer complicados. El uso de bibliotecas puede generar errores de tipos desconocidos o incompatibilidades de versiones de paquetes. Puede parecer excesivo. Las bases de código de TypeScript pueden parecer crípticas. Inicialmente, puede hacerte sentir que la productividad se ralentiza y de repente sientes que tienes que pensar en TypeScript, y viniendo de JavaScript, es muy extraño. ¿Eres tú o un colega? Nuevamente, son puntos realmente importantes. ¿Tu refactorización es inteligente, lo que la hace más rápida, básicamente, de escribir porque tienes sugerencias. ¿Tu incorporación para las personas, básicamente, tu código está documentado, y si escribes algo que no sea compatible con la base de código, se romperá o te lo dirá de inmediato para que no intentes pasar eso. Y hay objetivamente menos errores, nuevamente, recuerda lo que dijimos sobre el análisis de Airbnb. Pero específicamente relevante para el diseño atómico, es la misma forma de pensar. Es muy compatible. Cuando creas tus tipos, básicamente estás buscando similitudes entre las cosas que se deben pasar. Y los tipos también son la mejor forma de documentación. Al igual que tienes el storybook para lo visual. En nuestra opinión, TypeScript es básicamente el storybook de tu base de código. Es básicamente una documentación. La firma de la función es un teorema y el cuerpo de la función es la prueba. Y nuevamente, los tipos definen la forma en que los componentes de la interfaz de usuario se relacionan entre sí. Así es como debes ver tus tipos cuando los estás creando y lo que se necesita para que todo funcione como un sistema unificado. Deberías poder visualizar los componentes y jerarquías mientras lees tus tipos.

Y nuevamente, eso puede sonar obvio. Pero nuevamente, creo que no puedes subestimar hasta dónde puedes llegar con eso. Comprende hasta dónde pueden llevarte los tipos. Y para eso, creo que puedes tomar mucha inspiración en las bases de código de código abierto de las herramientas que realmente respetas y que usas todo el tiempo.

Definitivamente me ayudó cuando comencé mi startup a comprender qué tipos de datos podía pasar y cómo... Sabes cómo algunas personas aún son escépticas de TypeScript porque dicen que les hace pensar en TypeScript. Eso puede ser literalmente un superpoder, porque te hace pensar de manera diferente.

Y cuando ves bases de código de código abierto escritas en TypeScript, realmente te da inspiración para todas las puertas que puede abrir, para lo que puedes hacer. Aquí, por ejemplo, este es un archivo de entrada de número de Andy. Puedes ver todo lo que pasan por ahí. Entonces sí, puedes crear básicamente tu propia biblioteca de interfaz de usuario en tu base de código, donde puedes pasar el tamaño, muchas de las cosas que tu producto puede necesitar, y pasar enumeraciones, o algo así. Entonces nuevamente, toma inspiración y aprovecha los tipos de una manera que no podrías hacer solo con JavaScript, ya sea porque no es la forma en que te haría pensar, o porque significaría que es demasiado arriesgado, porque no estás seguro de qué pasar. Otras personas pueden no saber qué pasar. O necesitarás documentarlo todo. Y así es más fácil en JavaScript crear archivos duplicados.

Entonces sí, intenta aprovechar los tipos y busca inspiración en bases de código de código abierto realmente buenas para ver su poder.

Ahora, lo realmente importante aquí son los desafíos y consideraciones del mundo real. Problemas, o posibles problemas, que estoy seguro de que reconocerás, que creo que se agravan al usar TypeScript con diseño atómico. Así que es solo una palabra de precaución, algo en lo que debes tener cuidado al programar.

Hay una zona muy delicada entre la sobreingeniería temprana y complicar las cosas a futuro. Y escribir código que funcione ahora causará problemas enormes más adelante. Ahora, esto es fácil de detectar. Sabes, como programador, sabes cuando estás programando algo sobre la marcha y te dices a ti mismo, o estoy ocupado para hacerlo ahora, lo haré después, o no ahora, lo haré después, o esto es solo temporal. Sabes cuando estás haciendo algo que solo funciona por ahora. Como, por ejemplo, escribir 'any' en todas partes. Vale, funciona por ahora, 'any', lo que sea. Vale, eso lo sabes.

Esto es mucho más difícil de detectar. Porque nuevamente, conoces ese dicho que dice, el camino al infierno está pavimentado de buenas intenciones. También hay un camino hacia una base de código horrible, que también está pavimentado con buenas intenciones. Puedes tener un plan realmente bueno y ejecutarlo y no darte cuenta de que, en realidad, no está yendo bien. Es difícil de detectar porque generalmente lo detectas después. Vuelves a tu código y te das cuenta de lo complicado que es. O alguien más tiene que colaborar contigo y te preguntas, ¿qué es esto? Por lo general, lo detectas después de haber programado en lugar de antes.

Entonces, sí, una señal de que tal vez quieras tomar un descanso y pensarlo de nuevo es la nomenclatura. Esta es una gran señal de advertencia de sobreingeniería. Si tienes dificultades para encontrar los nombres correctos para tipos y variables, entonces sí, hay algo ahí. Normalmente, es como cuando dicen que si puedes explicar algo, significa que lo has entendido. Si no puedes nombrar algo, significa que hay algo en tu lógica que te falta o que puede que no entiendas completamente aunque sientas que sí lo haces. Es lo mismo. Los nombres básicamente explican lo que es y si no puedes nombrarlo, no puedes explicarlo. Es una señal de advertencia. Lo más probable es que pienses que sabes cómo funciona todo, pero en realidad no lo sabes, de nuevo. O puede que estés tratando de encajar demasiados propósitos diferentes en él. Bienvenido a la silla.

Entonces, la silla es un buen ejemplo de algo donde... Te doy un ejemplo, ¿vale? Como cuando estás escribiendo un archivo de índice donde tienes todos tus diferentes botones que puedes tener y alguien pasa un tema y diferentes props, y generará el botón correcto. Vale, genial. Ahora, es un problema cuando tus botones se vuelven tan diferentes en la interfaz de usuario y en las diferentes cosas que puedes tomar que probablemente deberías crear un archivo separado.

Deberías crear un archivo separado para los diferentes botones y tener un archivo de índice que los importe y exporte a todos. Y luego simplemente haces referencia al archivo directamente con las props requeridas correctas. Porque si tienes, por ejemplo, solo un archivo que tiene todos los botones en él, y luego toma un tema y muchas propiedades opcionales. Si tienes demasiadas propiedades opcionales, de todos modos no documenta tu código. Porque es como, ¿qué se supone que debo pasar? Puedo pasar 1000 cosas, que son requeridas, y que se romperían si no las paso. Así que nuevamente, realmente intenta cuando estés escribiendo tus tipos en TypeScript entender los límites. Cuando estás agregando propiedades opcionales y propiedades opcionales, en algún momento debes detenerte y crear un archivo separado, lo siento, un tipo separado. Cuando una de esas propiedades opcionales podría crear un problema si no se pasaran bajo una cierta condición de otra cosa dentro de la pestaña.

Entonces sí, bienvenido a la silla. No hagas eso. Así que sí, nuevamente, tómate un descanso. Sabes, porque luego abstraes demasiadas cosas y terminas con profundidad de código. Y nuevamente, puede ser fácil escribir algo nuevo, pero el mantenimiento puede ser un infierno. Así que no te felicites porque has codificado algo que funciona, que es una nueva funcionalidad, realmente, realmente entiende que necesitas tomar descansos. Y nuevamente, no solo es más difícil detectar la sobreingeniería demasiado temprano, también es mucho más difícil resolverla. Puedes refactorizar esto. Puedes refactorizar algo que has hecho donde te estás repitiendo, no has escrito ningún tipo y lo que sea. Vale, puedes crear un tipo después, entendiendo lo que era. Puedes refactorizar, pero para esto, tienes que reiniciar por completo. Y hay más falacia del costo hundido, lo que significa que mucha gente no reinicia. Solo intentan ajustar y ajustar y ajustar porque han invertido tanto en este plan de ingeniería, no solo tiempo, sino también esfuerzo en hacer que funcione que no reinician cuando deberían. Es más fácil refactorizar, duplicar código que se ha copiado y pegado. Es más fácil refactorizar código verboso o tipos que pueden surgir y deberías refactorizarlo. Es más difícil mantener algo corto que es más difícil de descifrar y entender porque tiene muchas ramificaciones que no ves porque solo ves dos líneas, pero no ves las consecuencias alrededor de eso. Y es más difícil reescribir algo que afecta nuevamente, muchas partes diferentes de la base de código. Así que te daré un breve ejemplo de cosas que a veces cuando estaba en el flujo hubiera querido refactorizar o abstraer aún más.

Entonces, este es un ejemplo, ¿vale? En esa aplicación, tienes feeds de esculturas, pinturas, música clásica, etc. Todo esto es en lo que gira la aplicación. Y aquí tengo básicamente un generador de tarjetas, que me dice, vale, dependiendo de la categoría pasada, mostraré cosas diferentes.

Y aquí podría no haberme repetido. Podría haber dicho en lugar de buscar, como tener el tipo de categoría siendo el más importante aquí, y repetir imágenes, podría haber tenido, ya sabes, un tipo iCard que tome, ya sabes, lo que pasa como un activo. Podrías tomar una imagen o podrías tomar un MP3. Y luego esto no se repetiría. Solo tendríamos casos, imagen, mostrar imagen, caso, música, mostrar música.

No, fui con esta repetición y eso fue honestamente mi salvación porque quieres mantenerte cerca del producto. Quieres evitar acumular excepciones impulsadas por el producto con el tiempo. Por ejemplo, cada categoría puede hacer lo que sea que puedan mostrar. Puedes crear matices en torno a eso y se pueden agregar sin tener que hacer muchos ajustes. Te daré un ejemplo. Tal vez tengas una escultura y una pintura que muestren imágenes. Sin embargo, la pintura puede mostrar algo encima de ella. Y luego tu switch case ya no funciona porque depende de la categoría. No depende de la imagen mostrada.

Entonces, sí, no quieres alejar el código base de donde realmente se está construyendo con abstracciones innecesarias. Tus tipos de interfaz de usuario deben documentar el código base del producto. Y deben ayudar a visualizar los productos a medida que avanzas en el código. Entonces, sí, mantente cerca de los productos. Asegúrate de que tu lenguaje de dominio esté cerca de los productos. Y si estás abstrayendo demasiado, lo verás porque no podrás visualizar lo que realmente estás construyendo cuando estás leyendo el código. Entonces, sí, nuevamente, si necesitas comentarios excesivos sobre lo que se supone que deben hacer tus tipos y ayudar con, eso también es una señal de alerta. En UI-UX, tus tipos deben servir como la documentation en sí y ser la fuente de aclaración. Y si necesitas comentar demasiado sobre eso, significa que no estaban haciendo el trabajo que se suponía que debían hacer. No están aclarando por sí mismos. Nuevamente, se proporcionan ejemplos de implementación práctica, porque eso es importante para que entiendas cómo se traduce en bases de código reales. Tengo en mi código esas carpetas.

Puedes llamarlo como quieras, pero esos nombres son muy buenos porque eran científicos, eran objetivos. Y cualquier otra persona en el equipo, cuando entienden la definición de cada uno, están alineados y no cambiarán con el tiempo.

Entonces, los átomos, las partes más pequeñas extremadamente utilizables. El 90% del estilo ocurre allí. Las moléculas, envío un pequeño grupo de átomos con un estilo mínimo, principalmente para que encajen bien juntos. Los organismos es lo que llamo la capa lógica de IU y UX. No hay estilo. Los componentes deciden la generación correcta de la IU de las moléculas y la funcionalidad basada en los datos que recibe. Las páginas solo están ahí para pasar datos. Obtiene los datos correctos y los pasa. Y las plantillas generalmente encapsulan una página, al menos para mí, y trascienden la página o serían los diseños principales.

Entonces, sí, un buen ejemplo de átomos sería, por ejemplo, aquí, el archivo de iconos donde no necesitarás, si necesitas cambiar un icono algún día, está todo en un solo lugar. Pasas todas las props que quieres, como el tamaño, el color, etc. Y luego las personas que trabajan contigo en una base de código saben exactamente qué iconos diferentes están disponibles y no necesitan buscarlo. Nuevamente, como párrafos, cosas como la tipografía. Las moléculas, un buen ejemplo es el formulario que se asegura de que cuando tienes un formulario, puedan mostrarse en diferentes IU. Entonces, nuevamente, puedes tener un formulario que esté en una fila, en una columna. Puedes tener algunos formularios que tengan una imagen, algunos que no. Eso sería, por ejemplo, algo bueno para una molécula y también el espaciado, como los espacios entre filas, por ejemplo, los espacios entre columnas, todas esas cosas. Pegando los átomos juntos.

Los organismos básicamente crean las moléculas y se aseguran de que, dados los datos que se les pasan, muestren lo correcto. Entonces, por ejemplo, aquí, si quiero mostrar un elemento de radio, entonces llamaré a la molécula que se encarga de unir los elementos de radio. Lo mismo para las casillas de verificación, las clasificaciones, etc. Crea las tarjetas, etc. Entonces, sí, el organismo es el tipo de máquina. Y sí, las plantillas, las transiciones, por ejemplo, buen ejemplo. Ya sabes, cuando desvaneces una página, cuando te desplazas hacia arriba, esas cosas encapsulan la página, pero también los menús que se mantienen entre páginas, etc., y los dispositivos.

Entonces, sí, los formularios creo que son muy importantes porque simplifican enormemente el uso de TypeScript para los formularios. Los formularios asustan a mucha gente, pero se pueden simplificar mucho y hacerlos reutilizables. Y creo que si echas un vistazo a este tipo de código, por ejemplo, puede darte inspiración sobre cómo puedes hacer tus formularios básicamente muy sencillos y muy simples al mismo tiempo.

Sí, y nuevamente, asegúrate de que tus tipos documenten realmente todo lo que se necesita para funcionar como un sistema unificado y que puedas visualizar tu producto cuando estás leyendo el código sin comentarios ni omisiones necesarias.

Sí, nuevamente, esto es para ti para que puedas echar un vistazo más tarde. Entonces sí, como conclusión, Atomic Design asegura que todos, usuarios y equipos, estén en la misma página visualmente, intuitivamente y en la mentalidad y TypeScript asegura que los ingenieros estén en la misma página a un nivel aún más profundo. Todo debe estar claramente definido y esperado. Recuerda las palabras de precaución y todo estará bien.

Para aquellos que desean adoptar una base de código existente a Atomic Design, diría que una buena manera de hacerlo es implementar storybook a medida que avanzas. Entonces sí, consulta storybook en línea e intenta adoptarlo y verás que te hará pensar en esos términos.

Algunas lecturas nuevamente, Brad Frost, cualquier cosa de Brad Frost es genial para leer. Él es básicamente el padre de Atomic Design y ha escrito mucho al respecto. Muchas gracias por asistir a mi charla. Nuevamente, consulta Custodian Careers con el tiempo. Amamos a los estudiantes ambiciosos y no dudes en contactarme y hacerme cualquier pregunta. Gracias.