Sistemas de Diseño: Encontrando el Equilibrio entre Flexibilidad y Consistencia

Rate this content
Bookmark

Los sistemas de diseño tienen como objetivo brindar consistencia al diseño de una marca y hacer que el desarrollo de la interfaz de usuario sea productivo. Las bibliotecas de componentes con una API bien pensada pueden hacer que esto sea muy fácil. Pero, a veces, la elección de una API puede excederse accidentalmente y ralentizar al equipo. Hay un equilibrio ahí... en algún lugar. Vamos a explorar algunos de los problemas y posibles soluciones creativas.

47 min
22 Oct, 2021

Video Summary and Transcription

La charla discute el equilibrio entre la flexibilidad y la consistencia en los sistemas de diseño. Explora el diseño de la API del componente ActionList y las opciones de personalización que ofrece. Se enfatiza el uso de APIs basadas en componentes y la composabilidad para la flexibilidad y personalización. La charla también aborda el componente ActionMenu y el concepto de construir para las personas. La sesión de preguntas y respuestas cubre temas como la inclusión de componentes en los sistemas de diseño, la complejidad de la API y la decisión entre crear un sistema de diseño personalizado o utilizar una biblioteca de componentes.

Available in English

1. Flexibilidad vs Consistencia en los Sistemas de Diseño

Short description:

Hola, soy Sid. Trabajo en el equipo de sistemas de diseño en GitHub. Quiero hablar sobre cómo encontrar el equilibrio entre flexibilidad y consistencia. He estado investigando otros sistemas de diseño en busca de inspiración y ideas para la API. Estuve analizando este alerta y tratando de construirla con Polaris de Shopify y la biblioteca de componentes de Material UI. Así es como difieren. Con Shopify, tienen una API de configuración muy controlada, mientras que Material UI ofrece más flexibilidad. El nivel de flexibilidad depende de varios factores como el público objetivo, la cultura de diseño y la madurez del producto. Es importante encontrar el equilibrio adecuado para tu biblioteca de componentes. ¡Gracias por venir a mi charla!

Hola, soy Sid. Trabajo en el equipo de sistemas de design en GitHub. Quiero hablar sobre cómo encontrar el equilibrio entre flexibilidad y consistencia. Así que empecemos directamente con código.

Tengo esta alerta que he estado analizando en otros sistemas de diseño en busca de inspiración, ideas para la API, y todo eso. Estuve analizando esta alerta y tratando de construirla con Polaris de Shopify y la biblioteca de componentes de Material UI. Así es como difieren.

Con Shopify lo llaman un banner. Renderizas un banner y luego le pasas un estado, en este caso el estado es crítico, y le pasas un título. Estas propiedades se pasan como configuración, ¿verdad? El título no se coloca en el hijo, se coloca en el componente como una propiedad. Luego tienes la acción y solo dices cuál es la acción y qué contenido se coloca dentro de la acción. No puedes elegir la acción en sí. El componente se encarga de dónde se renderiza, cómo se renderiza, qué color, el borde, todo eso. Este es un ejemplo de una API de configuración, que está muy controlada.

De hecho, si intentas, jugué con esto. Cuando intenté agregar una etiqueta de estilo, intenté darle diferentes nombres de clase. No acepta ninguno. Esto es lo que obtienes. Luego, cuando intenté construir lo mismo con Material UI, también tenían una severidad. Lo llaman error en lugar de crítico, pero es lo mismo. Podías darle cualquier icono que quisieras. Pude importar un icono de los iconos de Material y pasarlo. También pude darle diferentes estilos. Pude personalizar el borde. Y para el contenido interno, tuve que tomar el título de la alerta que exportan y tomar un botón e intentar hacer que el botón se vea exactamente como quiero. Además, el espacio entre ellos, tuve que hacerlo con el margen entre los componentes. Ese es solo un pequeño ejemplo de cómo la flexibilidad puede ser tan diferente entre dos componentes. Si comparas la API de estos, el de Shopify está muy controlado en comparación con el de Material UI, donde puedes personalizar prácticamente todo lo que quieras. Eso nos lleva a esta línea o este espectro de flexibilidad donde Polaris probablemente esté en algún lugar aquí. Es muy opinativo. Está construido para Shopify. No está construido para todos. Tiene una API muy estricta y eso lleva a resultados predecibles y consistentes. Cuando usas ese banner, sabes exactamente qué va a salir. Pero luego puede volverse rígido y restrictivo para experimentar o para diferentes casos de uso. Lo siento. Por otro lado, el de Material UI probablemente esté en algún lugar del extremo derecho. Incluso puede estar completamente allí. Y eso se debe a que es de código abierto. Tiene una API extremadamente flexible porque no tiene contexto de dónde se usará. Necesita ser flexible para que puedas adaptarlo al producto que estás construyendo. Y, por supuesto, con tanta personalización, puede volverse desordenado y fragmentado porque la biblioteca de componentes no tiene muchas decisiones de diseño incorporadas. Todas esas decisiones están en el lado del producto. Tomando esto en cuenta, ¿qué es lo correcto para ti? ¿Dónde debería estar tu biblioteca de componentes en el espectro de flexibilidad? Y la respuesta es que depende, ¿verdad? Siempre. Pero esto es en lo que depende. Depende de si tu biblioteca de componentes está construida para una marca o si está construida para código abierto, que es para todos. ¿Cuál es la cultura de diseño en la marca para la que trabajas? ¿Está consolidada con un pequeño grupo de diseñadores o son varios equipos independientes que operan prácticamente por su cuenta? E incluso, ¿cuál es la madurez de los productos en los que estás trabajando? ¿Tienes patrones establecidos o aún está en una etapa temprana y es más experimental, aún jugando para encontrar esos patrones?

Entonces, la respuesta básicamente es que depende, ¿verdad? Gracias por venir a mi charla. Adiós.

2. Componente ActionList y Diseño de API

Short description:

Este es un componente ActionList con varias variaciones utilizadas en GitHub. El diseño de la API explora el equilibrio entre el control y la flexibilidad. El menú se puede crear pasando elementos a la lista de acciones y definiendo el comportamiento al seleccionar. Para diferentes acciones, se considera una API de separador, con la opción de usar un texto específico o un tipo. ActionList.divider proporciona un buen equilibrio al ocultar los detalles de implementación.

Este es un componente ActionList dentro de una superposición. Y lo verás en todo GitHub. Hay muchas variaciones de esto, pero es un componente bastante complejo. Tiene muchas variaciones. Aquí tienes algunas de ellas. Lo verás en una página de repositorio. Justo al lado, lo verás como opciones en un menú desplegable. Lo verás en el panel de versiones. Este es el de versiones. También los verás al intentar seleccionar asignados o revisores. Así que hay muchas... Hay una gran variedad en este componente.

Y estaba tratando de averiguar cómo debería ser la API, qué tan controlada o flexible debería ser. Permíteme llevarte a través de ese proceso para que pueda cuantificar lo que significa `depende`. Así que hagamos este ejercicio de API desde el principio. Estoy construyendo esta lista de acciones. Esta es la página de problemas. Y una advertencia rápida para ti, ninguno de estos diseños es realmente de producción. Todos son parte de una exploración. Así que si no coincide exactamente con la estética de lo que ves en GitHub.com, eso es intencional. Todo esto es una exploración.

De acuerdo, eso aclarado, este es el menú que ves y tiene algunos estilos. Creo que tiene algunas interacciones con el teclado. Sí, ahí lo tienes. Para crear este menú, veamos, el menú más simple aquí podría ser, tienes una lista de acciones y simplemente le pasas elementos, y los elementos son estas opciones que vas a hacer. Y luego, al seleccionar, haces algo con ello. Puedes llamar a tu propia acción dependiendo de la cadena. Se siente un poco extraño hacer estas acciones basadas solo en el contenido de la cadena. Por ejemplo, si dices `responder cita`, esto es lo que obtienes a cambio. Se siente extraño actuar solo en una cadena. Entonces tal vez algo como esto es mejor, donde es una configuración, es un objeto, y luego puedes pasar tu función de selección. Dependiendo de la copia de eso, también puedes pasar lo que debería ser la selección. Y eso se siente decente.

Así que pasamos al siguiente caso de uso donde no todas estas tienen las mismas acciones. Algunas de ellas se basan en la acción de, ya sabes, sacarlas. Algunas de ellas se tratan del contenido en sí. Editar y eliminar. Y esto es tercero, que es, ya sabes, es un informe. Es algo de moderación. Entonces queremos separarlos con separadores y ahora, ¿cómo debería ser la API del separador? Lo pensé y estaba pensando que ya tienes texto, ¿debería ser como un texto secreto, como un texto muy específico que le das? Por ejemplo, si me das `separador subrayado`, entonces sé cómo poner un separador o tal vez no debería hacer eso en absoluto. Tal vez debería ser un tipo, ¿verdad? Y todos los demás son del tipo `fila` y este es del tipo `separador`. Pero luego, por supuesto, ¿es `separador` en minúsculas, en mayúsculas, todo eso? Tal vez deberías importarlo desde ActionList y luego es solo un valor en los objetos con el tipo ActionList.divider. Y si ya estás haciendo esto, entonces tal vez esto sea ActionList.divider, donde, ya sabes, ActionList.divider es un objeto que es un detalle interno que sabe cómo renderizar el separador. Esto se siente como un buen equilibrio donde ocultamos los detalles de implementación del separador. Nadie necesita saber que hay un tipo `separador`. Todo lo que haces es poner un ActionList.divider ahí. Se siente bien. De acuerdo, sigamos adelante. Siguiente caso de uso, algunos de estos son destructivos.

3. Personalización del Componente ActionList

Short description:

Eliminar comentario es algo destructivo. Queríamos tener un estilo diferente y más aterrador. Sigamos adelante. En el lado derecho del problema, verás todas estas opciones. Comencemos con las etiquetas. La diferencia aquí es que tiene un círculo, el color de la etiqueta. Parece inteligente. Pero cuando hablamos de asignados, los asignados no tienen etiquetas, tienen un avatar. Parece lo suficientemente inteligente. Podría ser un color de etiqueta o un avatar. El componente ActionList sabe cómo renderizar ambos. Parece bien. Pero luego tienes otras cosas como hitos, que tienen este icono, y proyectos, que tienen este icono. Tal vez solo necesitemos saber si es una etiqueta, un avatar o un icono. Y eso probablemente funcione, ¿no? Para un caso de uso de icono, tal vez solo importemos un icono de nuestra biblioteca de iconos y lo pasemos, para que los hitos sepan cómo renderizar un icono. Pero, ¿qué sucede si le das un avatar o un icono? Esta es una de esas situaciones en las que si la API te empuja en una cierta dirección, debería ser la dirección que deseas. No queremos que las personas tomen estas decisiones o caigan en estas trampas porque no están tratando de romper la API, solo están tratando de crear la función de selección. A partir de eso, nos damos cuenta de que solo debería haber un prefijo, puede ser un avatar, una etiqueta o un icono de selección, y lo importas y lo pasas como un elemento de prefijo. En este caso, solo obtienes uno, un avatar, pero por supuesto, si obtienes un elemento de prefijo, también necesitas pasarle una propiedad. Entonces obtienes algo como `prefixProps` donde tienes que pasar la URL del avatar. Y si lo piensas, esto es como si tuvieras un elemento y propiedades, esto es un componente, así que podríamos llamarlo simplemente componente. Entonces, este es un prefijo que acepta cualquier componente que desees e intenta colocarlo aquí. Definitivamente más flexible, definitivamente más en sintonía con lo que necesitamos que haga, pero el compromiso aquí es que puedes poner cualquier componente que desees. Esto abre más la API que solo tres configuraciones permitidas para poner lo que quieras, pero si quieres un icono, entonces puedes. Puedes importar el icono y poner el icono de verificación, que es lo que quería.

Eliminar comentario es algo destructivo. Queríamos tener un estilo diferente y más aterrador. Podría ser tan simple como agregar una variante. Todo es variante por defecto o variante sutil. Y este es variante peligro, parece. Parece encajar bien. Sigamos adelante.

Ahora, en el lado derecho del problema, verás todas estas opciones. Tienes etiquetas, asignados, revisores. Comencemos con las etiquetas. Así que si miras las etiquetas, es algo similar. Es una lista de acciones con opciones en las que puedes hacer clic. La diferencia aquí es que tiene un círculo, el color de la etiqueta. Entonces, para empezar, diría que pongamos todos los elementos aquí. Hay un texto. Hay un deseleccionar. Y hay un color de etiqueta. Porque solo tengo texto aquí, necesito algo para calificar que debe haber un círculo. Estoy poniendo esta clave especial inteligente aquí, que se llama color de etiqueta. Y si le pasas un valor hexadecimal, sabe que debe renderizar un color, renderizar un círculo con ese color. Y se encarga de cuál debería ser el margen, cuál debería ser la separación entre el color y el texto. Parece inteligente. Y sabes, lo haces con todos ellos, y realísticamente, si esto se usa en un producto, se verá algo así. Recorrerías las etiquetas del repositorio, o como una configuración de etiquetas, y extraerías el color de la etiqueta de ella. Parece inteligente. De acuerdo.

Pero cuando hablamos de asignados, los asignados no tienen etiquetas, tienen un avatar. Entonces, ¿simplemente hacemos repo.colaboradores, mapeamos a través de ellos, y luego tienes texto y onSelect, que es lo mismo. Pero en lugar de color de etiqueta, se convierte en avatar, y sabe que debe renderizar un círculo, cuánto espacio debe haber, y simplemente pasas la URL del usuario.avatar. Parece lo suficientemente inteligente. Entonces tenemos, podría ser un color de etiqueta o un avatar. Y el componente ActionList sabe cómo renderizar ambos. Parece bien. Pero luego tienes otras cosas como hitos, que tienen este icono, y proyectos, que tienen este icono. De hecho, si te muestro todos estos ejemplos, hay un montón de ellos. Algunos tienen iconos, otros no. Algunos tienen esta sangría, pero en general, parece que la mayoría de estos son avatares o iconos. Algunos son iconos de colores, pero siguen siendo iconos. Entonces, tal vez solo necesitemos saber si es una etiqueta, un avatar o un icono. Y eso probablemente funcione, ¿no? Para un caso de uso de icono, tal vez solo importemos un icono de nuestra biblioteca de iconos y lo pasemos, para que los hitos sepan cómo renderizar un icono. Pero, ¿qué sucede si le das un avatar o un icono? No estoy diciendo que las personas estén tratando activamente de hacer esto, están tratando de romper algo, pero es más como si estuvieran tratando de lograr algo más, como una selección y quieren poner una marca de verificación, ¿se siente como una solución factible? Entonces importas el icono de verificación y quieres mostrar una marca de verificación junto a la persona a la que se le asigna y terminarás con algo como esto en este caso donde no hay suficiente espacio para ambos, por lo que simplemente desplazan todo y luego estás pensando en cómo crear ese margen, cómo obtener más espacio, tal vez pueda sobrescribir algún margen con CSS y esta API parece que es una dirección válida, aunque no queremos que hagas eso con el componente, así que esta es una de esas situaciones en las que si la API te empuja en una cierta dirección, debería ser la dirección que deseas. No queremos que las personas tomen estas decisiones o caigan en estas trampas porque no están tratando de romper la API, solo están tratando de crear la función de selección. A partir de eso, nos damos cuenta de que solo debería haber un prefijo, puede ser un avatar, una etiqueta o un icono de selección, y lo importas y lo pasas como un elemento de prefijo. En este caso, solo obtienes uno, un avatar, pero por supuesto, si obtienes un elemento de prefijo, también necesitas pasarle una propiedad. Entonces obtienes algo como `prefixProps` donde tengo que pasar la URL del avatar. Y si lo piensas, esto es como si tuvieras un elemento y propiedades, esto es un componente, así que podríamos llamarlo simplemente componente. Entonces, este es un prefijo que acepta cualquier componente que desees e intenta colocarlo aquí. Definitivamente más flexible, definitivamente más en sintonía con lo que necesitamos que haga, pero el compromiso aquí es que puedes poner cualquier componente que desees. Esto abre más la API que solo tres configuraciones permitidas para poner lo que quieras, pero si quieres un icono, entonces puedes. Puedes importar el icono y poner el icono de verificación, que es lo que quería.

4. Personalización del Componente y Revisores

Short description:

Puedes pasar al componente visual principal diferentes elementos como el avatar, el color de etiqueta o el icono de hito. El campo de descripción permite diferentes estilos y variantes de texto. Los revisores tienen sugerencias en la parte superior y todos los demás en la parte inferior, con la capacidad de agrupar usuarios. La API utiliza metadatos de grupo e IDs para determinar el orden y permite diferentes variantes como lleno o sutil.

Podrías hacer algo así. Entonces no lo llamamos prefijo, lo llamamos componente visual principal, para que esté en sincronía con Figma, detalles de implementación pequeños, no deberían importar. Y funciona. Puedes pasarle el avatar, puedes pasarle el color de etiqueta, puedes pasarle el icono de hito. Por lo tanto, se adapta a todos estos casos de uso sin romper realmente la API. Así que me gusta.

Continuemos, hagámoslo más complicado, por supuesto. Así que mirando esto, ves etiquetas. En realidad, asignados. Mostramos el nombre del asignado junto a su identificador. Y tiene un estilo de texto diferente y aparece en línea en comparación con una etiqueta aquí. Puedes poner mucho más texto y se muestra en la siguiente línea. Creo que este patrón también está presente en hitos, en la siguiente línea, proyectos. Muestra el repositorio o la organización en la siguiente línea. Así que simplemente lo llamo descripción, ¿verdad? Esta es otra clave. No quiero que las personas cambien el color de texto ni nada por el estilo. Así que solo acepto un campo de texto aquí, que es user.name y también funciona para etiquetas porque podría ser la descripción de la etiqueta. Y luego, si lo quieres en la siguiente línea, le das una variante de bloques. Puede ser en línea. Puede ser bloque y lo llamo variante de descripción. Así que esto todavía está bastante agrupado. Como una API de configuración parece ser... Hay una salida de escape y hay como la fealdad de elemento y variante de elemento, pero en general parece que funciona bien. Así que sigamos con esto. Ahora hablemos de los revisores porque ese es un componente ligeramente más complicado. Así es como se ven los revisores. Verás que en los revisores tienes sugerencias en la parte superior y todos los demás en la parte inferior. Por lo tanto, tienes dos variaciones de esto. Tienes grupos de personas, que no es algo que tengas en los asignados. En los asignados es solo una lista plana, pero en los revisores está agrupado. Entonces, ¿cómo lidiamos con los grupos aquí? Tal vez solo pasemos el grupo para que sepas, si el usuario ha editado esto recientemente como una función, podría ser cualquier cosa. Luego va a las sugerencias, de lo contrario va a todos. Por lo tanto, todos con ese título se agrupan y sabemos que tenemos que renderizar las sugerencias antes del primero. Un poco desagradable, pero podría funcionar. Pero, ¿cómo decidimos qué viene primero? ¿Las sugerencias vienen primero para todos? Esto no es confiable, ¿verdad? Porque si el primero es todos, ¿entonces eso viene primero? ¿Tiene sentido? Entonces eso nos lleva a una API ligeramente diferente, donde queremos que los metadatos de grupo estén en la parte superior para que puedas declarar qué viene primero. Luego, ahora que tienes estos, no tenemos que depender de cadenas. Podemos hacer esto un ID. Entonces, si se ha editado recientemente, entonces debería ser el elemento cero, que son las sugerencias. Por lo tanto, tienes el ID de grupo aquí en lugar de grupo. Y si no, es el otro caso, que es uno, que es de este elemento, todos. Parece bien. También hice algo más, que está lleno en lugar de ser simple. Así que volvamos al anterior. Esto estaba en línea. En línea o sutil. Pero el siguiente está lleno. Y en diferentes áreas de GitHub se utilizan diferentes estilos para esto. Así que creo que en los revisores definitivamente usamos uno lleno, pero hay otros lugares donde no lo hacemos, donde usamos uno sutil. Entonces, en este caso, también tenemos que decir qué variante queremos. Queremos una variante llena para los revisores, no la sutil.

5. Flexibilidad de la API del Componente

Short description:

Y finalmente, queremos este encabezado que dice solicitudes de hasta 100 espectadores. Tenemos descripciones tanto en línea como en bloque. Si no queremos manejar casos específicos en la biblioteca de componentes, podemos delegar la responsabilidad al producto. Sin embargo, creo que hay un enfoque mejor. Necesitamos una API más flexible y componible que se encuentre en algún lugar entre una API basada en configuración y una biblioteca de estilo de código abierto. Esto se puede lograr utilizando componentes en lugar de objetos para renderizar elementos en la lista de acciones.

Y finalmente, queremos este encabezado, que dice solicitudes de hasta 100 espectadores. Así que puse el encabezado, puse título, porque eso es lo que también tiene el grupo. Y estas son APIs similares. Y esto es muy sutil y no está lleno, siempre es sutil. Por lo tanto, toma las mismas props. Parece bien, no estoy muy contento con los metadatos del grupo y el ID del grupo. Es como, ya sabes, tienes que crear esto, es como un efecto secundario de una API basada en configuración donde tienes este ID de grupo, pero luego tienes que crear otro objeto porque no puedes encajar eso en los elementos. No son elementos, es una jerarquía diferente, pero está bien así.

Y finalmente, tenemos esto, que solo estábamos tratando con un tipo de descripción, ya sea en línea o en bloque. Pero aquí tenemos ambos porque realmente queremos ver cuál es la razón por la que han sido sugeridos. Así que tenemos tanto en línea como en bloque. Y entonces, ¿cómo acomodas eso, supongo que haces esto donde en lugar de descripción, tienes descripciones en plural. Y puedes dar una matriz donde tienes dos textos y luego tienes dos variantes, una está en línea, otra está en bloque. Y no sé si das tres, supongo que entonces tiene que encajar en una de estas y luego la última gana o algo así. Así que puedes ver que estoy forzando a esta API a hacer demasiado. Y está luchando un poco, esta API ya no es la más intuitiva. Comenzó fuerte, pero ya no tanto. Y finalmente, si no queremos hacer esto, si queremos hacer algo como que hay un punto en el que dices, OK, este componente ha tenido suficiente y ahora no queremos ocuparnos de esto en el producto, en la component library. Esto parece trabajo para el producto. Tienes que delegar la responsabilidad y decir, ya sabes, esto es muy específico del producto. Esto no sucede en todo GitHub, solo sucede en esta pantalla. Por lo tanto, esto debería estar en el producto y no lo pondremos en el que es común para todos. Para eso, necesitas habilitar una forma en la que puedan hacer esto. E imagino que se vería algo así para la lista de elementos, excepto algo como una función de renderización de elementos. Correcto. Esto es como una función de renderización de propiedades. Y luego obtienes todas las props internas y estas son props útiles para, ya sabes, todo el comportamiento y estilos de hover y navegación por teclado. Tenemos muchas props para esto. Por lo tanto, queremos que todas esas se pasen. Pero luego, dentro de ella, siempre que pases todas las props internas, puedes decidir cómo quieres renderizar esto. Así que siempre y cuando uses los primitivos correctos, donde uses el mismo avatar que usamos y el mismo color de texto y tamaño de texto para esto. Todo funcionaría bien. Y este es el enfoque que toman muchas bibliotecas de componentes donde tienen una salida de escape, donde si las cosas se vuelven demasiado locas, se te permite, ya sabes, salir de eso y todo está bien. No soy muy fanático de este enfoque, porque es como delegar la responsabilidad. Me da un poco de miedo lo que sucede dentro de estas props internas si se aplica correctamente. Y puedes terminar rompiendo el comportamiento receptivo o el comportamiento accesible, si no se hace correctamente, si no se compone correctamente. Entonces puedes terminar construyendo componentes que no siguen las pautas, aunque hayas tomado todos los bloques de construcción de las pautas. Así que todo eso para decir que no creo que delegar la responsabilidad al producto siempre sea la mejor idea. Ya es como el último recurso, pero creo que podemos hacerlo mejor aquí. Aquí está el otro estilo de API. Creo que hemos visto claramente aquí que esta API necesita ser mucho más flexible. La API basada en configuración no se adapta bien a ella. Necesitamos una API más componible. Por lo tanto, en el espectro, necesitamos estar un poco más hacia el lado derecho. Tal vez no hasta el estilo de biblioteca de código abierto, pero en algún punto intermedio entre esos dos. Esto es cómo se vería con una API diferente donde tengo esta lista de acciones. Y luego para renderizar todos los elementos solíamos hacer esto, donde teníamos esta matriz de objetos. En cambio, obtienes un elemento diferente dentro de la lista de acciones. Que es solo un componente. Porque todo esto es JavaScript, lo que puedes hacer es crear un componente de lista de acciones, crear otro componente llamado elemento y luego adjuntarlo, porque todo son objetos, a la lista de acciones.

6. Composición del Componente de Lista de Acciones

Short description:

Y luego solo exportas uno, que es el padre. Así que terminas haciendo cosas como action list.item, y se mapea al elemento interno, lo cual es perfecto. Así que obtienes action list.item. Puedes poner el texto adentro. No necesitas decir prop de texto más, porque React ya tiene una forma de poner contenido dentro de un elemento. Se llama children. Así que puedes usar los children. Solo lo pones adentro y pasas el onSelect. Parece fácil, parece bastante similar, no tan diferente. Parece funcionar bien.

Y luego solo exportas uno, que es el padre. Así que terminas haciendo cosas como action list.item, y se mapea al elemento interno, lo cual es perfecto. Así que obtienes action list.item. Puedes poner el texto adentro. No necesitas decir prop de texto más, porque React ya tiene una forma de poner contenido dentro de un elemento. Se llama children. Así que puedes usar los children. Solo lo pones adentro y pasas el onSelect. Parece fácil, parece bastante similar, no tan diferente. Parece funcionar bien.

Moviendo a los separadores, este es el siguiente caso de uso. Así es como lo hicimos antes, donde teníamos algunas formas de decir de manera críptica qué es el separador. En este caso, creo que puede ser solo un componente, porque renderizas el separador de la lista de acciones. Y al igual que el elemento, es un componente y puedes ponerlo donde quieras. Y eso crea el separador. Ahí mismo. Parece igual. No muy creativo. Y luego tenías esta variante. Creo que voy a mantener ese comportamiento, la variante como una prop parece tener sentido. El valor predeterminado es en línea o sutil y puedes pasar la variante peligro. Bien.

Ahora, aquí es donde comienza a ponerse interesante. Para las etiquetas, ups, seleccionado. Para las etiquetas, lo que estábamos haciendo era tener este visual principal, ¿verdad? Y así es como se vería de forma predeterminada, dentro de la lista de acciones, recorrerías las etiquetas y luego usarías el elemento de la lista de acciones. Dale una clave porque ahora es un bucle. Estamos recorriéndolo. Y luego tienes el onSelect y, ya sabes, los children es donde va el nombre de la etiqueta. Así que podríamos simplemente poner algo antes de esto, como podríamos poner el componente de color de etiqueta, pero luego seríamos responsables de, ya sabes, cuál es el margen hacia la derecha y cosas así. En cambio, lo que podrías hacer es tener action list.visual principal como un componente, ¿verdad? Así que ves lo que estamos haciendo aquí. Estamos creando todos los componentes secundarios que se pueden componer juntos para crear este estilo. Y los children saben dónde deben ir. Como los estilos ya están dentro del componente, siempre terminan en la posición correcta. En este caso, el visual principal es esta área a la izquierda. Sabe cuánto margen poner. Sabe que tiene que centrar verticalmente todo el contenido dentro, y luego podríamos poner el color de la etiqueta. Si es la lista de colaboradores, si es esta lista, entonces sabemos que, ya sabes, tenemos que poner los avatares dentro y si tenemos, veamos.

De acuerdo, si tienes los hitos y proyectos, se ve bastante similar. Pasando a la descripción, porque parece ser la siguiente. Nuevamente, ¿va aquí la descripción? ¿Debo decir user.name? Pero también sé que tiene que tener un estilo diferente. Entonces tal vez usaría action list.description. En la API anterior era solo una variable aquí. En esto, es un componente y dices action list.description. Y ves, a medida que los colocamos, todos conocen su lugar en la fila de este componente, por lo que todos ocupan ese espacio, que ya está decidido. Y podrías usar un stack, podrías usar una cuadrícula para esto en la lista de acciones, y cada uno podría tener su propia posición en la cuadrícula. Así que básicamente es un componente de diseño en este punto. Y podrías poner cualquier cosa dentro de la descripción, lo cual es un poco aterrador porque en la API anterior podrías decir, esto es solo un texto. No puede ser otra cosa. Aquí tienes children, ¿así que los children pueden ser otra cosa? No es necesario, en realidad puedes...

7. API basada en ranuras de componentes y flexibilidad

Short description:

Puedes hacer que la descripción o los children tengan un tipo, lo que permite diferentes variantes y tipos. El componente utiliza una API basada en ranuras con ranuras predefinidas para visual principal, texto, descripción en línea y descripción en bloque. Rellena dinámicamente las ranuras en función de los componentes secundarios utilizados. El área central es de formato libre, lo que permite flexibilidad. El componente renderiza las ranuras utilizando Flexbox o diseño de cuadrícula. Se pueden agregar hitos, proyectos y etiquetas a las ranuras.

Oh, me salté una diapositiva. De acuerdo. Permíteme volver a ese punto. Pero las etiquetas, ¿recuerdas, tienen que ser variantes en bloque? Ya tenemos una descripción. Así que tenemos un lugar donde podemos colocar esa prop, que sería variant block. Eso está hecho. Ahora, volviendo a lo que estaba diciendo sobre el tipo, puedes hacer que la descripción o los children tengan un tipo, ¿verdad? Hay una forma de hacerlo. Dices usando TypeScript en este caso, pero también podrías hacerlo con tipos adecuados. Donde el tipo de descripción, la variante puede ser en línea o en bloque, pero los children deben ser una cadena. No tienen que ser children como un nodo, ¿verdad? Que es lo predeterminado en React. Podría ser cualquier cosa que quieras. Podrías tener un número si quisieras. Así que en este caso, simplemente escribimos children como una cadena. Y si intentas darle algo más, obtendrás una advertencia de que, ya sabes, por favor no lo hagas. No está permitido. Y para mostrarte cómo funciona realmente este componente, cómo caen exactamente las cosas en sus espacios, lo que tengo en este lugar, o al menos este que se muestra a la izquierda, es algo así como una API basada en ranuras. Tengo estas ranuras donde tengo esto es la visual principal. Esto es el texto. Esto es el espacio para la descripción en línea. Y luego tengo espacio para la descripción en bloque. Y lo que estoy haciendo es, si usas los children de ActionList, si usas los componentes que enviamos con él, miramos el child.type, así que estoy recorriendo todos estos children, mirando el child.type. Y si hay cosas que ya identificamos, entonces relleno las ranuras. Entonces, por ejemplo, la visual principal, si el tipo de componente es ActionList.leadingVisual, que enviamos, va a la ranura de visual principal. Así que si intentas pasar varias visual principal, bueno, supongo que la última gana, y eso está totalmente bien. Muestra que solo acepta una. Y tenemos lo mismo para la descripción. Si es descripción y es una variante en bloque, va a la descripción en bloque, de lo contrario, va a la descripción en línea y todo lo demás va al texto, ¿verdad? Así que la parte de texto aquí es algo que tengo en un array. Así que podrías poner varios bloques de texto allí si quisieras. Y esa es la única parte de formato libre aquí. Todo lo demás está tipificado y tiene un lugar. Pero el área central es algo en lo que puedes poner cualquier cosa. Así que esa es la que mantenemos libre. Y luego también tengo algún estado de selección, que, ya sabes, no necesito mostrarte por ahora. Pero aparte de eso, es tu buen viejo componente. Renderiza una ranura. Si no hay nada en la ranura, no renderiza nada. Simplemente queda vacío. Pero estoy usando Flexbox. Puedes usar cuadrícula. Es una cosa de diseño. Así que las ranuras como elección de API. Muy genial. Me gusta. Veamos si funcionan las cosas de hitos y proyectos. Tenemos las visual principal. Tenemos el nombre. Tenemos la descripción. Y puedes ver que puedo cambiar lo que va en el medio. Lo que va dentro de la ranura. Y puedo obtener hitos, proyectos, etiquetas, todos ellos encajan en la ranura.

8. Composición de Componentes y Selección de Hitos

Short description:

Así que solo estoy cambiando la ranura. El resto de la estructura es la misma. Ahora, hablemos de esta revisión. En los revisores, estamos cambiando un poco el paradigma. Dentro de la lista de acciones, queremos poner dos grupos de elementos. Así que acabo de crear un grupo de lista de acciones, con el mismo estilo que antes. Se compone muy bien. Hemos podido tomar todas las partes sin romper la API y seguir componiéndolas. Continuando desde aquí, el hito es una visual principal, pero también tiene este efecto genial donde puedes seleccionar algo. Hay muchas cosas que podrías hacer. Probablemente podrías mostrar simplemente la marca de verificación como un ícono de verificación. Pero también queremos que este espacio esté abierto, ¿verdad? Esto no funciona muy bien. Necesitas saber que una de las ranuras está ocupada.

Así que solo estoy cambiando la ranura. El resto de la estructura es la misma. Es perfecto. Muy bien. Ahora, hablemos de esta revisión. En los revisores, ¿recuerdas que teníamos esa cosa de metadatos, que no me gustaba? En este caso, estamos cambiando un poco el paradigma. Dentro de la lista de acciones, queremos poner dos grupos de elementos. Así que acabo de crear un grupo de lista de acciones, con el mismo estilo que antes. Y toma un título. Toma una variante. Y honestamente, este título no es un texto, porque quiero llenar este grupo con todos los elementos. Así que el grupo tiene hijos y los hijos son en realidad elementos de lista de acciones. Así que puedo mapear a través de las personas sugeridas y ponerlas aquí. Y puedo mapear a través de todos los demás y ponerlos en el segundo grupo. Entonces, ya sabes, no hay mapeo, no hay metadatos. Todo se trata de pensar en un grupo a la vez y luego llenar con las personas que van dentro. Y dentro de eso tienes lo mismo que acabamos de ver. Tienes una visual principal, que tiene un avatar, tienes el texto, tienes la descripción, nada demasiado complicado. Simplemente funciona. Se compone muy bien, como si no tuviéramos que aprender nada nuevo. No hay props adicionales en el elemento. La única nueva API fue para el grupo y está completamente autónoma. Así que ves que estamos tomando diferentes caminos y los estamos componiendo entre sí. Y parecen encajar muy bien desde el punto de vista de la API. Finalmente, recuerda que teníamos estas dos descripciones. Una en línea y otra en bloque. ¿Cómo las encajamos? Bueno, simplemente ponemos dos descripciones, supongo. Así que tienes descripción de lista de acciones variante en línea y tenemos descripción de lista de acciones variante en bloque. Y ambas se colocan una al lado de la otra y, ya sabes, no importa en qué orden las pongas porque tenemos las ranuras y las ranuras tienen el espacio específico para ocupar. Así que sí, simplemente puedes poner dos descripciones si quieres. Funciona bastante bien. Muy bien. Finalmente, hice un componente de encabezado, que toma el título y la variante. Una vez más, quería poner el título dentro porque, ya sabes, React tiene una forma de poner hijos, pero para que sea consistente con la API del grupo, sigo el título y la variante en su lugar. Una elección pequeña, pequeña. Muy bien. Así que ahora, si comparas, esto es lo que parecía en los metadatos del grupo en la API de configuración anterior, donde tenías metadatos del grupo, tenías que hacer coincidirlo con el ID del grupo, teníamos que hacer esta representación de escape para las descripciones. Y aquí, definitivamente, ya sabes, parece mucho más largo, pero también es más componible. Hemos podido tomar todas las partes sin romper la API y seguir componiéndolas y realmente funciona muy bien. Muy bien. Así que, continuando desde aquí, veamos si funcionan las otras cosas. El hito es una visual principal, pero también tiene este efecto genial donde puedes seleccionar algo, ¿sabes? Y esto ni siquiera lo mencionamos en la API de configuración porque, bueno, ya sabes, realmente no tenía espacio para ello. Pero en este caso, hay muchas cosas que podrías hacer. Probablemente podrías mostrar simplemente la marca de verificación como un ícono de verificación, ya sabes. Así que, si este hito está seleccionado, entonces pon una marca de verificación aquí. Pero también queremos que este espacio esté abierto, ¿verdad? Porque queremos que estos estén alineados. No queremos que estos dos estén alineados a la izquierda y luego no haya espacio. Así que esto no funciona muy bien. Necesitas saber que una de las ranuras está ocupada.

9. Selección de ActionList y Escalado de API

Short description:

Puedes usar el componente ActionList.selection para manejar el comportamiento de selección única y múltiple. Esto simplifica la API al renderizar automáticamente el estilo de selección adecuado según la variante de selección. La API basada en slots asegura que el componente sepa dónde renderizar la selección.

Entonces, tal vez hagamos esto que hemos estado haciendo hasta ahora. Tienes action list dot check. Y luego pasas checks si está marcado como verdadero, entonces se renderiza esto. Si está marcado como falso, entonces sabe que tiene que poner un espacio vacío aquí. Funciona más o menos. En el caso de las etiquetas, en realidad, veamos a los asignados. En el caso de los asignados, sin embargo, notarás que ya no es una marca de verificación. Es una casilla de verificación porque es una selección múltiple, no solo una. Así que, ya sabes, no queremos cerrar esto con una marca de verificación. En realidad, queremos mantener esto abierto, poner todas las marcas de verificación. Así que, tal vez en lugar de check solo hagamos checkbox y luego se envía a. Más o menos. Pero creo que hay una forma más sencilla porque, para ser honesto, según si es una selección única o una selección múltiple, queremos cambiar el comportamiento, es decir, ¿se cierra instantáneamente o no? Y queremos cambiar cómo se ve la selección. Así que voy a reemplazar esto con ActionList.selection. Y el ActionList sabe qué selección poner según la variante de selección o tal vez un nombre diferente para esto, ya sabes, selección única, selección múltiple. He elegido la variante de selección donde puedes hacerla única o múltiple. Y en función de esto, el ActionList sabe qué estilo de selección renderizar, ¿verdad? Entonces se convierte en algo menos de una API. No tienes que elegir entre una casilla de verificación o una marca de verificación, un icono de verificación. Solo tienes que decir, tengo selección en esto. Así que, colocas ese componente contra la API basada en slots. Sabe... ¿Qué hice? Oh, hice clic. Entré en su perfil. Dame un segundo. Necesito volver atrás. Volver atrás. ¿No? Oh, ahí vamos. Entonces, sí, debido a los slots, sabe exactamente dónde renderizarlo y elige según la variante de selección. Así que la API se está escalando bien.

10. Componente Action Menu y APIs Componibles

Short description:

Con el componente del menú de acciones, puedes usar action menu dot anchor para definir el elemento de anclaje. Todo lo que coloques dentro del componente se renderizará dentro del overlay. Puedes agregar diferentes componentes como un menú, un selector de emojis o una lista de acciones con una variante de selección. Para implementar un patrón de búsqueda, puedes renderizar un campo de texto dentro del overlay y usar un divisor de menú de acciones o un divisor de lista de acciones para el comportamiento deseado. El componente action menu dot text input proporciona estilos de enfoque y te permite controlar el estado y el comportamiento mientras el producto controla el diseño y el comportamiento. Las APIs componibles te permiten combinar componentes del producto y de la biblioteca de componentes, brindando flexibilidad y opciones de personalización.

Y finalmente, no hemos hablado realmente de cómo se renderiza esto en el menú. Hasta ahora, hemos estado viendo esto, el contenido interior. Pero ¿qué pasa con el menú de acciones? ¿El overlay? ¿En qué haces clic para obtener esto? Así que eso no es una lista de acciones, es un componente diferente llamado menú de acciones. Los nombres son similares porque queremos acoplarlos muchas veces. Así que déjame ver. Bien, este no es el ejemplo. Entonces, con el menú de acciones, lo que obtienes es un action menu dot anchor. Por ejemplo, estos tres puntos son un anclaje para ese caso. Pero en este caso, todo esto es un anclaje. Así que tienes asignados y tienes este engranaje, y toda la fila es un anclaje. Así que básicamente puedes poner lo que quieras. Tengo asignados y engranajes y están alineados y demás. Pero aparte de eso, cualquier otra cosa que ponga aquí se renderiza dentro del overlay. Así que el menú de acciones esencialmente utiliza slots, sabe qué es un anclaje, sabe que todo lo demás depende de ti. Así que puedes poner un menú, puedes poner un selector de emojis. Debería tener el ejemplo, deberías poner el selector de emojis aquí. O puedes poner una lista de acciones con una variante de selección y eso va dentro del overlay. ¿Qué pasa con este patrón que a veces ves donde puedes tener una búsqueda? Así que puedo buscar a Mike y esta lista se filtra. Así que queremos poner algo más aquí. Ahora, en una API basada en configuración, tendrías que declarar esto, ese filtro de usuario, o filtro true, y luego se renderizaría el campo de entrada. Tendrías que darle un marcador de posición, encontrar un usuario, tendrías que decir qué sucede cuando cambia. Así que estás viendo un montón de variables de configuración, una lista de nuevas props que se agregarían a la API de nivel superior. En este caso, creo que podemos hacerlo de manera más sencilla, renderizando un campo de texto. Si lo renderizas aquí en el área abierta, irá dentro del overlay. ¿Correcto? Irá dentro del cuerpo de él, y justo antes de la lista de acciones, puedes agregar un divisor de menú de acciones o un divisor de lista de acciones, son prácticamente lo mismo para obtener este comportamiento. Y porque queremos algunos estilos de enfoque, mira esto. Si estoy seleccionando, puedo moverme con el teclado, pero mi estado de selección seguirá aquí para que pueda seguir escribiendo. Este comportamiento es muy específico. Para hacer eso, en realidad enviamos action menu dot text input. Y esto es como, renderiza el texto y renderiza el divisor. Renderiza todo el comportamiento, pero básicamente puedes darle cualquier marcador de posición que quieras. Oh, mira, todavía está bloqueado en eso. Puedes darle cualquier marcador de posición que quieras, como este. Este dice, encontrar un usuario. Y luego en el on change, dices, filtrar usuarios, y luego eres responsable de filtrar. Así que controlas todo el estado en el producto, lo cual tiene sentido. Y el componente controla el diseño y el comportamiento, pero no el estado. Tiene mucho sentido. Esto es solo un ejemplo de cómo puedes usar APIs componibles para componer componentes del producto y componer componentes de la biblioteca de componentes, ponerlos todos juntos. Y aún así funciona, porque hemos pensado en todos esos casos de uso donde no sabemos realmente qué pondrán las personas aquí, pero sabemos que quieren poner cosas en el overlay. Así que les damos ese slot, que es como un slot abierto, y pueden llenarlo con las cosas que deseen.

11. Flexibilidad y Construcción para las Personas

Short description:

Experimenta para encontrar tu posición en el espectro de flexibilidad-consistencia. Los sistemas de diseño y las bibliotecas de componentes son para las personas que construyen productos, no solo para la API. La composición permite la flexibilidad. Construye para las personas, recuerda que estás construyendo para las personas. Echa un vistazo a Primer y al sistema de diseño en GitHub.

De acuerdo. Veamos. Entonces, para resumir, experimenta para descubrir tu posición en ese espectro de flexibilidad-consistencia, ¿verdad? Como alguien más no puede decirte eso realmente. Tienes que conocer la cultura de tu empresa. Debes conocer los tipos de casos de uso que atiendes. En nuestro caso, pensé que estábamos más del lado de la consistencia, pero en realidad en muchos casos, tenemos que serlo, GitHub es lo suficientemente grande como para serlo, ya sabes, hay muchos casos de uso. Así que probablemente estemos un poco más hacia el lado componible, más flexibles. Pero aún puedes usar la composición para permitir flexibilidad sin expulsar, ¿verdad? Y eso me lleva al último punto, como los sistemas de diseño son para las personas, las bibliotecas de componentes son para las personas. Cita brillante. Me encanta esto. Esto es de Gina. Y el resumen es que las personas que usan nuestros componentes solo intentan construir los productos, ¿verdad? Están tratando de construir productos para sus clientes. No están tan interesados en qué es la API o no están súper interesados en, la corrección de la API. Es agradable cuando la API se siente bien. Es agradable cuando la API es consistente. Todas esas cosas son importantes, por supuesto. Pero eso no es lo principal. Lo principal es qué puedes construir con el componente para que puedas construir algo para el cliente. Entonces, y esto es como, realmente me gusta la idea de la composición, permitiendo esa flexibilidad porque las personas tienen que hacer el trabajo. Si tu biblioteca de componentes no lo hace, lo harán con otra cosa. Construirán sus propios componentes personalizados, ¿verdad? Como aún tienen que hacer el trabajo. Esa es la idea. Experimenta para saber dónde estás en el espectro, usa la composición en lugar de expulsar de sistemas. Y finalmente, recuerda que estás construyendo para las personas. Gracias. Eso es todo. Si quieres ver Primer. Si quieres ver el sistema de diseño, está aquí, está en github.com. Y ese es mi Twitter. Si te gustó lo que escuchaste, si quieres más de eso, eso es todo. Así que ciao.

QnA

Q&A Session

Short description:

Estoy bien. ¿Cómo estás? Bien. Bien. Me encanta la charla. Una de las primeras preguntas es sobre decidir si un componente debe formar parte del sistema de diseño basado en su uso. Otra pregunta es cómo decidir si un componente debe dividirse para admitir diferentes casos de uso sin que la API sea demasiado compleja. Lidiar con excepciones de diseño se puede hacer utilizando patrones compuestos o estilos anidados. La decisión entre crear tu propio sistema de diseño o usar una biblioteca de componentes depende del nivel de personalización requerido y la etapa del proyecto. Por último, hay una pregunta sobre los libros coordinados por colores en el fondo.

Estoy bien. ¿Cómo estás? Bien. Bien. Me encanta la charla. Realmente estaba disfrutando eso. Y voy a volver y terminarlo más tarde. Pero tengo algunas preguntas que han llegado. Y solo te las voy a plantear.

Una de las primeras es, en pocas palabras, ¿hay una regla general para decidir si un componente debe formar parte del sistema de diseño? ¿Cuántas veces necesitas usarlo? ¿Hay un número suficiente de usos para tomar esa decisión? Esa es una muy buena pregunta. Supongo que la regla general es algo que insinuaste, que es cuántas veces se usa, especialmente en diferentes páginas y productos. Entonces, en el momento en que ves que algo es un patrón que se repite mucho, pero por supuesto, cada producto o cada equipo lo desarrollaría para su propio caso de uso. Es una señal de que entre equipos y productos, sería un poco inconsistente o podría ser accesible en uno pero no en el otro. Así que esa suele ser una señal segura de que esto podría ser incluido en el sistema, pulido, hecho consistente y luego liberado para que los equipos usen esa única versión verdadera. Eso es genial. Gracias.

Y una cosa que realmente me encantó mientras ibas a través de la charla fue que la fuiste construyendo poco a poco y vimos cómo este sistema de diseño se volvía cada vez más complejo. Y hay una pregunta relevante sobre esto, donde alguien pregunta cómo decides si un componente debe dividirse en varios componentes para admitir diferentes casos de uso sin que esa API se vuelva demasiado compleja. Sí, esa es una buena pregunta de nuevo. No sé si hay una respuesta fácil para eso, aparte de que estás tratando de construir algunos ejemplos con él y puedes, como intenté hacer en la charla, puedes empezar a darte cuenta cuando empieza a ser incómodo de usar. Cuando empieza a ser un poco demasiado, tienes que hacer demasiadas conjeturas o copiar exactamente de la documentación. Así que cuando ya no es predecible, cuando usas la API y realmente no puedes decir qué va a pasar. Esa suele ser una señal de que este componente está haciendo demasiado y podrías beneficiarte de un componente especializado o la API simplemente va en la dirección equivocada y tienes que dividirla. En la segunda mitad verás que adopto un enfoque más componible. Así que es la misma cantidad de componentes, uno con un montón de hijos, pero es una API más componible, por lo que realmente puedes hacer más manteniendo la API más pequeña. Gracias.

Y otra pregunta también, porque siempre habrá excepciones de diseño. Cuando intentas lidiar con ellas, ¿los patrones compuestos son la única forma de ser lo suficientemente flexibles pero seguir siendo abstractos? Al menos en mi experiencia, esa es la forma que más me gusta. Algunas personas también tienen estilos anidados, por lo que básicamente los pasas a la raíz y puedes referenciar cada hijo y personalizarlos. Entonces, tal vez en la lista de nivel superior, puedo decir que todas las imágenes, en realidad deberían tener este borde adicional, porque así lo elegí. Pero me gusta colocarlos juntos, ¿verdad? Lo más cerca posible de ellos. Así que generalmente prefiero el compuesto, pero es CSS. Puedes comenzar desde arriba y hacerlo en cascada. Genial. Y otra cosa en la que quiero conocer tu opinión, ¿cuál es tu opinión sobre crear tu propio sistema de diseño versus usar una biblioteca de componentes? Sé que, como dijiste, depende. Pero, ¿cómo sueles tomar esa decisión? En realidad, no tengo una buena respuesta, así que voy a dar la respuesta que personalmente hago. Que es comenzar con una biblioteca, que esperemos que sea sin estilos. Ahora hay algunas. Con eso, al menos puedes controlar el estilo, pero eventualmente siempre llego a un punto en el que quiero personalizarlo más y tengo que ir al interior. Así que en el momento en que te encuentras personalizando el comportamiento y no solo la estética, eso es una señal de que debes sacar este componente y construirlo desde cero. Hazlo tuyo. Pero honestamente, si miras una biblioteca de componentes y piensas que estamos contentos con el comportamiento que este componente nos brinda, especialmente si estás en una etapa temprana, no tienes que obtener todo exactamente como quieres. Y eres un poco más flexible. El envío es más importante que... Es mi opinión, creo. Entonces, sí, usa una biblioteca de componentes. Intenta encontrar una sin estilos, porque al menos quieres que se sienta como tu propia empresa. No quieres que se sienta como la de otra persona. Y se nos acabó el tiempo, pero quiero hacer una pregunta más para ti. ¿Deliberadamente coordinaste por colores los libros que tienes en el fondo? Sí, sí. Es cierto. Todos estos están coordinados por colores. Algunos de estos ni siquiera son míos. No los he leído. Son de mi esposa. Pero los tomé prestados solo para que todavía pueda decodificar. Genial. Los puse ahí porque hace que la transición sea más suave. Eso es agradable. Muchas gracias, Sid. ¡Todos aplaudan a Sid, que los escuche!

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
Top Content
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
Top Content
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 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
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.

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
Top Content
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
Top Content
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 Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
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
React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A