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

Rate this content
Bookmark

Todos mencionan la importancia de la "escalabilidad" y "mantenibilidad" del código y cómo TypeScript ayuda con ello. Pero cuando comencé en tecnología, recuerdo haber tenido dificultades para encontrar un ejemplo práctico y "real" con las mejores prácticas.

Mi charla tiene como objetivo proporcionar un ejemplo práctico y paso a paso, compartiendo algunos de mis aprendizajes y deficiencias: crucialmente, cómo aprovechamos TypeScript y Atomic Design, sin sobreingeniería demasiado temprana.

27 min
21 Sep, 2023

AI Generated Video Summary

Aprovechar TypeScript y Atomic Design puede resolver los problemas de estructura del código y lograr legibilidad, eficiencia y flexibilidad. TypeScript ofrece beneficios como refactorización inteligente, mejora de la incorporación y menos errores. TypeScript te hace pensar de manera diferente y abre puertas a lo que puedes hacer. Los desafíos y consideraciones del mundo real pueden agravarse al usar TypeScript con atomic design. Evita la sobreingeniería y la profundidad del código, y mantente cerca del producto para mantener la alineación de la base de código.

1. Introducción a los dilemas comunes de estructura de código

Short description:

Hola, bienvenidos a mi charla, Aprovechando TypeScript y Atomic Design, un Enfoque Pragmático. Como introducción, me gustaría repasar los dilemas comunes en la estructura de código y luego comprender los fundamentos de TypeScript y Atomic Design. La parte más importante son los desafíos y consideraciones del mundo real que es posible que no encuentres en línea. Y, por supuesto, te mostraré algunos ejemplos prácticos de implementación.

Así que esta es la estructura de la charla para que pueda seguirla. Como introducción, me gustaría repasar los dilemas comunes en la estructura de código y luego comprender los fundamentos de TypeScript y Atomic Design. Me gustaría ir rápido en eso. Creo que la parte más importante, realmente, son los desafíos y consideraciones del mundo real que es posible que no encuentres en línea. Y, por supuesto, te mostraré algunos ejemplos prácticos de implementación. Entonces, primero, los dilemas comunes en la estructura de código. Cuando comencé en tecnología después de mi bootcamp, estaba buscando buenos consejos sobre cómo estructurar tus códigos de la manera correcta, y esas tres palabras estaban en todas partes en teoría. Legibilidad, eficiencia, flexibilidad. Y suena bien. Pero cuando realmente comienzas a codificar y construir productos, te das cuenta de que rápidamente pueden volverse contradictorios en la práctica.

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

2. Descubriendo Atomic Design y TypeScript

Short description:

Comienzo del día cero, pánico, ¿qué estoy haciendo? Me encontré con Atomic Design con Airbnb y me di cuenta del poder de construir sobre los hombros de gigantes. De manera similar, mi descubrimiento de TypeScript a través de bibliotecas de código abierto y la migración de Airbnb a TypeScript confirmaron su efectividad. Aprovechar TypeScript y Atomic Design juntos puede resolver los dilemas de código y lograr legibilidad, eficiencia y flexibilidad.

rápidamente y luego planificar y hacerlo correctamente. Así que sí, esto es lo que sucede. Comienzo del día cero, pánico, ¿qué estoy haciendo? Y esto es lo que hice. Pensé en un producto que admiraba y investigué activamente cómo esa empresa lo había logrado. Y así fue como me encontré con Atomic Design con Airbnb. Mi mentor me dijo que debes construir sobre los hombros de los gigantes cuando eres básicamente una startup. Y eso es lo que hice. Tomé inspiración de todas estas empresas y todas tenían algo en común, y era Atomic Design. Así que sí, así fue como lo descubrí. Y nuevamente, en cuanto a TypeScript, en realidad estaba usando JavaScript todos estos años y así fue como también me encontré con él. Estaba pensando en una biblioteca que me gustaba mucho usar y que quería escalar de la misma manera. Y era de código abierto, así que revisé su código fuente y era TypeScript. Así que sí, todas las bibliotecas de interfaz de usuario que me encantaban usaban TypeScript. Así fue como supe que había algo bueno allí. Y después de realizar más investigaciones, vi que Airbnb también estaba migrando a TypeScript en ese momento. Y su análisis posterior mostró que el 38% de los errores en el código de Airbnb se podrían haber evitado con TypeScript. Así que sí, eso es cómo se unieron esas dos cosas. Y estoy feliz de compartir años después y después de construir muchas funcionalidades que esas dos cosas juntas son extremadamente poderosas y pueden resolver la mayoría de los dilemas de código que acabamos de ver y lograr REF, que básicamente significa legibilidad, eficiencia, flexibilidad y encontrar las líneas correctas y matices entre ellas para tener algo que sea realmente robusto y donde tú

3. Comprendiendo Atomic Design y TypeScript

Short description:

Comprendiendo TypeScript y los fundamentos atómicos. Atomic Design se trata de pensar de manera rigurosa y científica. Es una nueva forma de pensar para los desarrolladores front-end, organizando patrones automáticamente en tu mente. Visualiza cómo debería ser el código, comenzando con los componentes más pequeños y combinándolos en componentes más grandes de manera progresiva. Al observar las páginas, nota las variables cambiantes y los elementos consistentes.

también puedes colaborar con otras personas. Entonces, una vez más, seré breve en eso, comprendiendo TypeScript y los fundamentos atómicos. Puedes encontrar muchas cosas en línea. Pero repasemos eso para que todos estemos en la misma página.

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.

4. Simplificando Formularios y Comprendiendo TypeScript

Short description:

En tu estructura de código, visualiza cómo pueden funcionar las cosas. Los formularios pueden simplificarse enormemente al darse cuenta de sus similitudes y utilizar generadores de formularios. Mira el storybook de Airbnb para inspiración. Comprende el escepticismo en torno a TypeScript y empatiza con tus colegas. TypeScript puede parecer complicado, pero ofrece beneficios como refactorización inteligente, mejor incorporación y menos errores. TypeScript es el storybook de tu base de código, proporcionando documentación y definiendo las relaciones entre componentes.

Lo único que cambia es esto. Entonces, nuevamente, en tu estructura de código, visualizas cómo pueden funcionar las cosas. Y, nuevamente, esto también es una pregunta, especialmente en torno a los formularios. Los formularios, cuando hablo con otros desarrolladores frontend, es algo que odian. Pero creo que los formularios también se pueden simplificar enormemente al darse cuenta de cuánto tienen en común y cómo puedes crear generadores de formularios donde es realmente divertido construir. Y simplifica las cosas enormemente porque lo ves desde una perspectiva completamente diferente y ves más similitudes que diferencias.

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.

5. Aprovechando el poder de TypeScript y los tipos

Short description:

No puedes subestimar hasta dónde pueden llevarte los tipos. TypeScript te hace pensar de manera diferente y abre puertas a lo que puedes hacer. Observa las bases de código de código abierto escritas en TypeScript para inspirarte. Aprovecha los tipos para crear tu propia biblioteca de interfaz de usuario y simplificar el desarrollo.

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.

6. Desafíos y Consideraciones

Short description:

Intenta aprovechar los tipos y encontrar inspiración en bases de código de código abierto. Los desafíos y consideraciones del mundo real pueden agravarse al usar TypeScript con diseño atómico. Ten cuidado con la sobreingeniería temprana y el posible caos que puede causar. Detectar estos problemas puede ser difícil, pero tener dificultades con los nombres puede ser una señal de advertencia de sobreingeniería o falta de comprensión.

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.

7. Evitando la Sobreingeniería y la Profundidad del Código

Short description:

Entonces, la silla es un buen ejemplo de cuando los botones se vuelven demasiado diferentes en la interfaz de usuario, es mejor crear un archivo y tipo separado. Tómate descansos para evitar la sobreingeniería y la profundidad del código. Refactorizar código duplicado o tipos verbosos es más fácil que mantener un código corto y difícil de entender. Reescribir algo que afecta a múltiples partes de la base de código es más difícil. Aquí tienes un breve ejemplo de cosas que me hubiera gustado refactorizar o abstraer.

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.

8. Alineación del Código Base y Ejemplos Prácticos

Short description:

En este ejemplo, la aplicación gira en torno a feeds de esculturas, pinturas y música clásica. El generador de las tarjetas determina qué mostrar según la categoría. En lugar de repetir imágenes, se podría haber utilizado un solo tipo 'iCard' para manejar diferentes activos. Al mantenerse cerca del producto y evitar abstracciones innecesarias, el código base se mantiene alineado con el producto real. Los tipos de interfaz de usuario deben servir como documentación y ayudar a visualizar el producto. Los comentarios excesivos en los tipos indican la necesidad de mejorar. Se proporcionan ejemplos de implementación práctica para una mejor comprensión.

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.

9. Understanding Atomic Design and Code Structure

Short description:

Puedes llamarlo como quieras, pero esos nombres son muy buenos porque eran científicos, eran objetivos. Entonces, los átomos, las partes más pequeñas extremadamente utilizables. El 90% del estilo ocurre allí. Las moléculas, un pequeño grupo de átomos con un estilo mínimo para que encajen bien juntos. Los organismos, la capa lógica de IU y UX. Las plantillas encapsulan una página y las transiciones encapsulan la página. Los formularios se simplifican enormemente utilizando TypeScript para los formularios.

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.

10. Conclusion and Resources

Short description:

Asegúrate de que tus tipos documenten todo lo necesario para un sistema unificado. Atomic Design garantiza que todos estén en la misma página visual e intuitivamente. TypeScript asegura que los ingenieros estén en la misma página. Implementa Storybook para adoptar Atomic Design. Lee a Brad Frost. ¡Gracias por asistir!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up