Sistemas de Diseño: Caminando la Línea Entre Flexibilidad y Consistencia

Rate this content
Bookmark

Los sistemas de diseño buscan aportar 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 facilitar esto. Pero, ¡a veces una elección de API puede accidentalmente sobrepasar y ralentizar al equipo! Hay un equilibrio allí... en algún lugar. Exploremos algunos de los problemas y posibles soluciones creativas.

Siddharth Kshetrapal
Siddharth Kshetrapal
47 min
22 Oct, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La Charla discute el equilibrio entre flexibilidad y 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 componibilidad para la flexibilidad y personalización. La Charla también toca 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 sistemas de diseño, la complejidad de la API, y la decisión entre crear un sistema de diseño personalizado o usar una biblioteca de componentes.

Available in English

1. Flexibilidad vs Consistencia en Sistemas de Diseño

Short description:

Hola, soy Sid. Trabajo en el equipo de sistema de diseño en GitHub. Quiero hablar sobre caminar la delgada línea entre la flexibilidad y la consistencia. Tengo esta alerta que he estado mirando en otros sistemas de diseño para inspiración, para ideas de API, todo eso. Y estaba mirando esta alerta e intentando construirla con Polaris de Shopify y la Biblioteca de Componentes de Material UI. Así es como difieren. Con Shopify, es una API de configuración estrictamente controlada, mientras que Material UI ofrece más flexibilidad. El espectro 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 correcto para tu biblioteca de componentes. ¡Gracias por venir a mi charla!

Hola, soy Sid. Trabajo en el equipo de sistema de diseño en GitHub. Quiero hablar sobre caminar la delgada línea entre la flexibilidad y la consistencia. Así que comencemos directamente con code.

Tengo esta alerta que he estado mirando en otros sistemas de diseño para inspiración, para ideas de API, todo eso. Y estaba mirando esta alerta e intentando construirla con Polaris de Shopify y la Biblioteca de Componentes de Material UI. Así es como difieren.

Así que con Shopify lo llaman banner. Así que renderizas un banner y luego toma un estado, en este caso el estado es crítico, y toma un título. Así que toma estas propiedades como configuración, ¿verdad? Así que el título no va en el hijo, va en el componente como una propiedad. Y luego tienes la acción y solo dices cuál es la acción y cuáles son los contenidos que van dentro de la acción. Realmente no llegas a elegir la acción por sí misma. Y el componente se encarga de dónde se renderiza, cómo se renderiza, qué color, el borde, todo eso. Así que este es un ejemplo de una API de configuración, que está muy controlada.

Y de hecho, si lo intentas, jugué con esto. Cuando intenté dar una etiqueta de estilo, intenté darle diferentes nombres de clase. No acepta ninguno. Esto es lo que obtienes. Y luego cuando intenté construir lo mismo con Material UI, tenían una gravedad también. Lo llaman error no crítico, que es todo lo mismo. Pero podrías darle cualquier icono que quieras. Así que pude importar un icono del icono Material y pasarlo. También podría darle diferentes estilos. Así que pude personalizar el borde. Y para los contenidos dentro, 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 yo quiero. Más el espacio entre ellos, tuve que hacerlo con el margen entre los componentes. Así que eso es solo un pequeño ejemplo de cómo la flexibilidad puede ser tan diferente entre dos componentes. Como si comparas la API de estos, la de Shopify está súper controlada versus la de Material UI puedes personalizar básicamente cualquier cosa que quieras. Eso nos lleva a esta línea o este espectro de flexibilidad donde Polaris probablemente esté en algún lugar aquí. Así que es muy opinado. 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 lo que va a salir. Pero entonces podría volverse rígido y restrictivo para la experimentación o diferentes casos de uso. Lo siento. Por otro lado, el de Material UI probablemente esté en algún lugar en el borde derecho. Tal vez incluso todo el camino allí. Y eso es porque es de código abierto. Tiene una API extremadamente flexible porque no tiene contexto de dónde se usará. Así que necesita ser flexible para que puedas encajarlo en el producto que estás construyendo. Y luego, por supuesto, con tanta personalización, puede volverse desordenado y fragmentado porque, bueno, la biblioteca de componentes no tiene muchas decisiones de diseño incorporadas. Todas esas están en el lado del producto. Así que tomando esto, es como, ¿qué es lo correcto para ti? ¿Dónde debería caer tu biblioteca de componentes en el espectro de flexibilidad? Y la respuesta es que depende, ¿no es así? Siempre. Pero esto es de lo que depende. Depende de si tu biblioteca de componentes está construida para una marca o está construida para código abierto? Que es como 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 es un montón de 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 todavía es temprano y es más experimental, todavía jugando para encontrar esos patrones?

Así que la respuesta entonces básicamente es que depende, ¿verdad? Gracias por venir a mi charla. Adiós. Pero no, intenté usar estos e intenté aplicarlos a este componente.

2. Componente ActionList y Diseño de API

Short description:

Este es un componente ActionList con varias variaciones utilizadas en GitHub. El recorrido del 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 divisor, con la opción de usar un texto específico o un tipo. ActionList.divider proporciona un buen equilibrio al ocultar el detalle de implementación.

Este es un componente ActionList dentro de una superposición. Y lo verás repartido por GitHub. Hay muchas variaciones de esto, pero este es un componente bastante involucrado. Así que tiene un montón de variaciones. Y estas son algunas de ellas. Así que lo ves en una página de repositorio. Justo al lado, ves esto como opciones en un menú desplegable. Ves estos como en el panel de lanzamientos. Este es el de los lanzamientos. También los ves al intentar seleccionar asignados o revisores. Así que hay un montón de... Hay mucho rango en este componente.

Y estaba tratando de averiguar cómo debería ser la API, ¿cuánto control o flexibilidad debería tener? Y déjame llevarte a través de ese viaje, 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 rápida advertencia para ti, ninguno de estos diseños es realmente producción design. Todos son de una exploración. Así que si no coincide exactamente con la estética de lo que ves en GitHub.com, eso es realmente intencional. Todo esto es una exploración.

Bueno, dicho esto, este es el menú que ves, y tiene algunos estilos. Creo que tiene algunas interacciones de teclado. Sí, ahí lo tienes. Así que para hacer este menú, veamos, el menú más sencillo 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. Así que puedes llamar a tu propia acción dependiendo de la cadena. Se siente un poco raro hacer estas acciones basándose sólo en el contenido de la cadena. Como si dices respuesta de cita, esto es lo que obtienes a cambio. Así que se siente raro actuar sólo en una cadena. Así que tal vez algo como esto es mejor donde es una configuración, es un objeto, y luego puedes pasar en tu on select. Así que 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. Así que algunas de estas se basan en la acción de, ya sabes, como, llevarlo fuera. Algunas de estas son sobre el contenido en sí. Así que editar y eliminar. Y esta es la tercera, que es, ya sabes, es un informe. Es una cosa de moderación. Así que queremos separarlos con divisores y ahora ¿cómo debería ser la API del divisor? Así que pensé en ello y estaba pensando que ya tienes texto, ¿debería ser como un texto secreto muy específico que das. Como si me das un divisor de subrayado, entonces sé cómo poner un divisor o tal vez no debería hacer eso en absoluto. Tal vez debería ser un tipo, ¿verdad? Y todos los demás son de tipo fila y este es de tipo divisor. Pero entonces, por supuesto, ya sabes, ¿es un divisor en minúsculas, un divisor en mayúsculas, todo eso? Así que tal vez deberías importarlo de la ActionList y entonces es sólo un valor en los objetos con ActionList.divider type. Y si ya estás haciendo esto, entonces tal vez esto es ActionList.divider, donde, ya sabes, ActionList.divider es un objeto que es un detalle interno que sabe cómo renderizar el divisor. Esto se siente como un buen equilibrio donde estamos ocultando el detalle de implementación del divisor. Nadie necesita saber que hay un tipo divisor. Todo lo que haces es poner un ActionList.divider allí. Se siente bien. OK, sigamos. Siguiente caso de uso, algunos de estos son destructivos.

3. Personalización del Componente ActionList

Short description:

Así que eliminar comentario es algo destructivo. Queríamos tener un estilo diferente, más aterrador. Sigamos. En el lado derecho del problema, verás todas estas opciones. Empecemos 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 tienen, no tienen etiquetas, tienen avatar. Así que parece lo suficientemente inteligente. Así que tenemos, podría ser un color de etiqueta, o podría ser un avatar. Correcto, y el componente ActionList sabe cómo renderizar ambos. Parece bien. Pero entonces tienes otras cosas como hitos, que tiene este icono, tienes proyectos, que tiene este icono. Tal vez solo necesitamos saber si es una etiqueta o un avatar o un icono. Y eso probablemente solo funciona, ¿no es así? Para un caso de uso de icono, tal vez simplemente importamos un icono de nuestra biblioteca de iconos y lo pasamos, por lo que los hitos saben cómo renderizar un icono. Pero, ¿qué pasa si le das un puerto de avatar o de icono? Así que esto es una de esas cosas en las que si la API te empuja en una cierta dirección debería ser la dirección que quieres. No quieres que la gente tome estas decisiones, que caiga en estas trampas porque no están tratando de romper la API, solo están tratando de crear la función de selección. Así que a partir de eso me doy cuenta de que solo debería haber un prefijo, solo debería haber un visual ser un avatar, podría ser una etiqueta, podría ser el icono de selección y lo importas y lo pasas como un elemento prefijo. Así que en este caso solo obtienes uno, obtienes un avatar, pero por supuesto si obtienes un elemento prefijo entonces también necesitas pasarlo como una propiedad. Así que obtienes algo como tal vez prefijo props donde tengo que pasar la URL del avatar. Y si lo piensas, esto es como si tienes un elemento y propiedades, esto es un componente así que bien podríamos llamarlo un componente. Así que esto es un prefijo que acepta cualquier componente que quieras y trata de ponerlo aquí. Ahora definitivamente más flexible, definitivamente más en sincronía con lo que necesitamos que haga, pero la compensación aquí es que podrías poner cualquier componente que quieras. Así que esto abre la API más 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 es lo que quería.

Así que eliminar comentario es algo destructivo. Queríamos tener un estilo diferente, más aterrador. Podría ser tan simple como añadir una variante. Así que todo es variante por defecto o variante sutil. Y este es variante peligro, parece. Parece que encaja bien. Sigamos.

Ahora, en el lado derecho del problema, verás todas estas opciones. Tienes etiquetas, tienes asignados, tienes revisores. Empecemos con las etiquetas. Así que si miras las etiquetas, es algo similar. Es una lista de acciones con opciones que puedes hacer clic. La diferencia aquí es que tiene un círculo, el color de la etiqueta. Así que para empezar, diría que simplemente pongamos todos los elementos aquí. Hay un texto. Hay un deseleccionar. Y hay un color de etiqueta. Como solo tengo texto aquí, necesito algo para calificar que debería haber un círculo. Estoy poniendo esta clave inteligente especial aquí, que se llama color de etiqueta. Y si le pasas un valor hexadecimal, sabe que tiene que 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 el espacio entre el color y el texto. Parece inteligente. Y sabes, así que lo haces con todos ellos, y realísticamente, si esto se está utilizando en un producto, se verá algo así. Recorrerías repo.labels, o como una configuración de etiquetas, y sacarías el color de la etiqueta de él. Parece inteligente. Vale.

Pero cuando hablamos de asignados, los asignados tienen, no tienen etiquetas, tienen avatar. Así que simplemente hacemos repo.collaborators, los recorremos, y entonces tienes texto y onSelect, que es lo mismo. Pero en lugar de color de etiqueta, se convierte en avatar, y sabe que tiene que renderizar un círculo, cuánto espacio debería haber, y simplemente pasas el user.avatar.url. Así que parece lo suficientemente inteligente. Así que tenemos, podría ser un color de etiqueta, o podría ser un avatar. Correcto, y el componente ActionList sabe cómo renderizar ambos. Parece bien. Pero entonces tienes otras cosas como hitos, que tiene este icono, tienes proyectos, que tiene este icono. De hecho, si te muestro todas estas muestras, hay un montón de estas. Algunas de ellas tienen iconos, algunas de ellas no. Algunas de ellas tienen esta sangría, pero en general, parece que la mayoría de estas son avatares o sus iconos. Algunos de los iconos de colores, pero siguen siendo iconos. Así que tal vez solo necesitamos saber si es una etiqueta o un avatar o un icono. Y eso probablemente solo funciona, ¿no es así? Para un caso de uso de icono, tal vez simplemente importamos un icono de nuestra biblioteca de iconos y lo pasamos adelante, por lo que los hitos saben cómo renderizar un icono. Pero, ¿qué pasa si le das un puerto de avatar o de icono? No estoy diciendo que la gente esté 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 esto como una solución factible? Así que importas el icono de verificación y quieres mostrar la marca de verificación al lado de la persona a la que está asignado y terminarás con algo como esto en este caso donde no hay suficiente espacio para ambos, así que simplemente cambian todo y luego estás pensando en cómo creo ese margen, cómo consigo más espacio, tal vez puedo sobrescribir algo de margen con CSS y esta API parece que esa es una dirección válida aunque no queremos que hagas eso con el componente así que esto es una de esas cosas donde si la API te empuja en una cierta dirección debería ser la dirección que quieres. No quieres que la gente tome estas decisiones, que caiga en estas trampas porque no están tratando de romper la API, solo están tratando de crear la función de selección. Así que a partir de eso me doy cuenta de que solo debería haber un prefijo, solo debería haber un visual ser un avatar, podría ser una etiqueta, podría ser el icono de selección y lo importas y lo pasas como un elemento prefijo. Así que en este caso solo obtienes uno, obtienes un avatar, pero por supuesto si obtienes un prefijo elemento entonces también necesitas pasarlo como una propiedad. Así que obtienes algo como tal vez prefijo props donde tengo que pasar la URL del avatar. Y si lo piensas, esto es como si tienes un elemento y propiedades, esto es un componente así que bien podríamos llamarlo un componente. Así que esto es un prefijo que acepta cualquier componente que quieras y trata de ponerlo aquí. Ahora definitivamente más flexible, definitivamente más en sincronía con lo que necesitamos que haga, pero la compensación aquí es que podrías poner cualquier componente que quieras. Así que esto abre la API más 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 es lo que quería.

4. Personalización del Componente y Revisores

Short description:

Puede pasar al componente visual líder diferentes elementos como el avatar, el color de la etiqueta o el icono del 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 ID para determinar el orden y permite diferentes variantes como lleno o sutil.

Podrías hacer algo así. Así que no lo llamamos prefijo, lo llamamos visual líder, así que está en sincronía con Figma, pequeños detalles de implementación, no debería importar. Y funciona. Puedes pasarle el avatar, puedes pasarle el color de la etiqueta, podrías pasarle el icono del hito. Así que se ajusta a todos estos casos de uso sin realmente romper la API. Así que me gusta.

Sigamos, hagámoslo más complicado, por supuesto. Así que mirando esto, ves las etiquetas. En realidad, los asignados. Mostramos el nombre del asignado justo al lado de su identificador. Y tiene un estilo de texto diferente y se muestra en línea versus una etiqueta aquí. Puedes poner mucho más texto en él y se muestra en la siguiente línea. Creo que este patrón también está en los 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? Este es otro campo. No quiero que la gente cambie el color del texto o algo así. Así que simplemente estoy aceptando un campo de texto aquí, que es user.name y también funciona para las etiquetas porque podría ser cuál es la descripción de la etiqueta. Y luego si lo quieres en la siguiente línea, entonces le das una variante de bloques. Podría ser en línea. Podría 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 escotilla de escape y hay como el elemento y la fealdad de la variante del elemento, pero en general parece estar funcionando bien. Así que sigamos con esto. Ahora hablemos de los revisores porque es un componente un poco más complicado. Así es como se ven los espectadores. Verás que en los revisores tienes suggestions en la parte superior y tienes a todos los demás en la parte inferior. Así que 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. ¿Cómo lidiamos con los grupos aquí? Tal vez solo pasamos el grupo, ya sabes, si como el usuario ha editado recientemente esto como una función, podría ser cualquier cosa. Entonces va a suggestions, de lo contrario va a todos. Así que todos con ese título se agrupan y sabemos que tenemos que renderizar las suggestions antes del primero. Algo pegajoso, pero podría funcionar. Pero, ¿cómo decidimos qué viene primero? ¿suggestions viene primero para todos? Esto no es fiable, ¿verdad? Porque si el primero es todos, ¿entonces eso viene primero? ¿Tiene sentido? Así que eso nos lleva a una API ligeramente diferente, donde queremos que los metadatos del grupo estén en la parte superior para que puedas declarar qué viene primero. Entonces ahora que tienes estos, no tenemos que depender de las cadenas de texto más. Podemos hacer esto ID. Así que si se ha editado recientemente, entonces debería ser el elemento cero, que es suggestions. Así que tienes la ID del grupo aquí en lugar de grupo. Y si es de otra manera, es como el otro caso, que es uno, que es de este elemento, todos. Parece bien. También hice algo más, que es esto está lleno en lugar de estar vacío. Así que volvamos al anterior. Esto estaba en línea. En línea o sutil. Pero el siguiente está realmente lleno. Y diferentes áreas en GitHub usan 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. Así que 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 el título, porque eso es lo que también tiene el grupo. Y estas son APIs similares. Y esto es muy poco sutil y no, esto no está lleno, esto siempre es sutil. Así que toma las mismas propiedades. Parece bien, no estoy muy contento con los metadatos del grupo y la ID del grupo. Es como, ya sabes, tienes que crear esto es como un efecto secundario de la API basada en configuración donde tienes esta 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 pero está bien así.

Y finalmente, tenemos esto, que es que solo estábamos tratando con un tipo de descripción, era en línea o era 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 en línea y en bloque ambos. Y entonces, ¿cómo acomodas eso, supongo que haces esto donde en lugar de descripción, tienes descripciones en plural. Y puedes dar un array donde tienes dos textos y luego tienes dos variantes, una es en línea, una es en bloque. Y no sé si das tres, supongo que entonces tiene que caer en una de estas y entonces 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. Empezó fuerte, pero ya no tanto. Y finalmente, si no queremos hacer esto, si quieres hacer algo como que hay un punto en el que dices, OK, este componente ha tenido suficiente y ahora no queremos cuidar de esto en el producto, en la component library. Esto parece un trabajo para el producto. Tienes que delegar la responsabilidad y decir, ya sabes, esto es como la inversión de responsabilidad y decir, esto era muy específico del producto. Esto no es algo que suceda en todo GitHub, esto solo sucede en esta pantalla. Así que esto debería estar en el producto y no lo pondremos en el que es común para todos. Así que para eso, necesitas habilitar alguna forma de que puedan hacer esto. Y me imagino que se parece algo a esto para la lista de elementos, excepto algo como una función de renderizado de elementos. Correcto. Esto es como una función de prop de renderizado. Y luego obtienes todas las propiedades internas y estas son propiedades que son útiles para, ya sabes, todos los comportamientos y estilos de desplazamiento y navegación con el teclado. Tenemos muchas propiedades para esto. Así que queremos que todas esas se pasen. Pero luego dentro de él, siempre y cuando pases todas las propiedades internas, puedes decidir sin embargo quieres renderizar esto. Así que siempre y cuando uses los primitivos correctos, donde usas el mismo avatar que usamos y el mismo color de texto y tamaño de texto para esto. Todo funcionaría. Y este es el enfoque que muchas bibliotecas de componentes toman donde tienen una escotilla de escape, donde si las cosas se vuelven demasiado locas, se te permite, ya sabes, desviarte de y todo está bien. No soy un gran fan de este enfoque, porque es como simplemente delegar la responsabilidad. Me da un poco de miedo lo que sucede dentro de estas propiedades internas si se aplican correctamente. Y puedes terminar rompiendo el comportamiento responsive o accesible, si no se hace correctamente, si no se compone correctamente. Así que puedes terminar construyendo componentes que no siguen las guidelines, aunque hayas tomado todos los bloques de construcción de las guidelines. Todo eso para decir que no creo que delegar la responsabilidad en el producto sea siempre 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 le va muy bien. Necesitamos una API más componible. Así que en el espectro necesitamos estar un poco más hacia el lado derecho. Tal vez no todo el camino hasta la biblioteca de estilo de código abierto, pero en algún lugar entre los dos. Así es como 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 este array de objetos. En cambio, obtienes un elemento diferente dentro de la lista de acciones. Así que es solo un componente. Porque esto es todo Java Script, lo que puedes hacer es crear un componente de lista de acciones, crear otro componente llamado elemento, y luego adjuntarlo, porque son todos 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, que es perfecto. Así que obtienes action list.item. Puedes poner el texto dentro. Se llama children. Pasando a los divisores, renderizas el divisor de la lista de acciones. Y al igual que el item, es un componente y puedes ponerlo donde quieras. Para las etiquetas, puedes tener action list.leading visual como un componente. En este caso, leading visual es esta área a la izquierda. Sabe cuánto margen poner. Y luego podríamos poner el color de la etiqueta. Pasando a la descripción, podrías usar una pila, 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.

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

Pasando a los divisores entonces, este es el siguiente caso de uso. Así es como lo hicimos antes, donde teníamos algunas formas crípticas de decir qué es el divisor. En este caso, creo que puede ser simplemente un componente, porque renderizas el divisor de la lista de acciones. Y al igual que el item, es un componente y puedes ponerlo donde quieras. Y eso crea el divisor. Justo ahí. Parece lo mismo. 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 predeterminado es en línea o sutil y puedes pasar la variante peligro. Bien.

Ahora, aquí es donde empieza a ponerse interesante. Para las etiquetas, vaya, seleccionado. Para las etiquetas, lo que estábamos haciendo era que teníamos este leading visual, ¿verdad? Y así es como se vería por defecto, dentro de la lista de acciones, mapearías a través de las etiquetas y luego usarías el item de la lista de acciones. Le das una clave porque ahora es un bucle. Estamos mapeando a través de él. Y luego tienes el onSelect y luego, ya sabes, los children es donde va el nombre de la etiqueta. Así que podríamos poner algo antes de esto, como podríamos poner el componente de color de la 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.leading visual como un componente, ¿verdad? Así que ves lo que estamos haciendo aquí. Estamos creando todos los componentes hijos que pueden componerse juntos para crear este estilo. Y los children saben a dónde deben ir. Como los estilos ya están dentro del componente, siempre terminan en la posición correcta. Así que en este caso, leading visual 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.

Bien, así que si tienes los hitos y proyectos, se ve muy similar. Así que pasando a la descripción, porque parece que es lo siguiente. De nuevo, ¿va la descripción aquí? Como, ¿digo user.name? Pero luego también sé que tiene que tener un estilo diferente. Así que tal vez usaría action list.description. En la API anterior era solo una variable aquí. En esta, es un componente y dices action list.description. Y ves, a medida que vamos colocando estos, todos saben su lugar en la fila de este componente, así que todos ocupan ese espacio, que ya está decidido. Y podrías usar una pila, 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 anterior API podrías decir, esto es solo un texto. No puede ser otra cosa. Aquí tienes children, ¿pueden los children ser algo más? No es necesario, en realidad puedes...

7. API basada en Componentes Slot y Flexibilidad

Short description:

Puedes hacer que la descripción o los children sean tipados, permitiendo diferentes variantes y tipos. El componente utiliza una API basada en slots con slots predefinidos para visualización líder, texto, descripción en línea y descripción en bloque. Rellena dinámicamente los slots en función de los componentes hijos utilizados. El área media es de forma libre, lo que permite flexibilidad. El componente renderiza los slots utilizando Flexbox o diseño de cuadrícula. Los hitos, proyectos y etiquetas se pueden añadir a los slots.

Oh, me salté una diapositiva. Vale. Permíteme volver a ese punto. Pero las etiquetas, ¿recuerdas que tenían que ser variantes de bloque? Ya tenemos una descripción. Así que tenemos un lugar donde podemos poner esa prop, que sería la variante de bloque. Así que eso está hecho. Ahora, volviendo a lo que decía sobre el tipo, puedes hacer que la descripción o hacer que los children sean tipados, ¿verdad? Hay una forma de hacer eso. Que es, dices usando TypeScript en este caso, pero podrías hacerlo con tipos adecuados también. Donde el tipo de descripción, la variante puede ser en línea o en bloque, pero los children tienen que ser una cadena. No tienen que ser children como un nodo, ¿verdad? Que es lo predeterminado con React. Podría ser cualquier cosa que quieras. Podrías tener un número si quisieras. Así que en este caso, simplemente tipamos children como una cadena. Y si intentas darle algo más, obtienes una advertencia de que, ya sabes, por favor no hagas eso. No está permitido. Y para mostrarte cómo funciona este componente, ¿cómo caen exactamente las cosas en sus espacios? Lo que tengo en este lugar, o al menos este que se renderiza a la izquierda, es que tengo algo como una API basada en slots. Así que tengo estos slots donde tengo esto es la visualización líder. Este es el texto. Este 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 lleno los slots. Así que, por ejemplo, la visualización líder, si el tipo de componente es ActionList.leadingVisual, que enviamos, va al slot de visualización líder. Así que si intentas pasar varias visualizaciones líderes, supongo que la última gana, y eso es totalmente bien. Kind of shows that it only accepts one. Y tenemos lo mismo para la descripción. Si es descripción y es una variante de bloque, va a la descripción de bloque, de lo contrario va en línea y todo lo demás va al texto, ¿verdad? Así que la parte del texto aquí es algo que tengo en un array. Así que podrías poner varios bloques de texto allí si quisieras. Y eso es lo único de forma libre aquí. Todo lo demás está tipado y tiene un lugar. Pero el área media es algo que podrías poner cualquier cosa. Así que eso es lo que mantenemos libre. Y luego tengo algún estado de selección también, que, ya sabes, no necesito mostrarte todavía. Pero aparte de eso, es tu buen viejo componente. Renderiza un slot. Si no hay nada en el slot, no renderiza nada. Simplemente queda vacío. Pero estoy usando Flexbox. Puedes usar cuadrícula. Es una cosa de diseño. Así que los slots como una elección de API. Muy guay. Me gusta. Veamos si funcionan las cosas de hitos y proyectos. Así que tenemos las visualizaciones líderes. Tenemos el nombre. Tenemos la descripción. Y puedes ver que puedo cambiar lo que va en medio. Lo que va dentro del slot. Y puedo obtener hitos, proyectos, etiquetas, todos ellos encajan en el slot.

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

Short description:

Así que solo estoy cambiando el slot. El resto de la estructura es la misma. Ahora, hablemos de esta revisión. En los revisores, estamos cambiando 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. Pasando de esto, el hito es una visualización líder, pero también tiene este efecto genial donde puedes seleccionar algo. Hay un montón de cosas que podrías hacer. Probablemente podrías mostrar la marca de verificación como un icono de verificación. Pero también queremos que este espacio se abra, ¿verdad? Esto no funciona. Necesitas saber que uno de los slots está lleno.

Así que solo estoy cambiando el slot. El resto de la estructura es la misma. Es perfecto. Muy bien. Ahora, hablemos de esta revisión. Entonces, en los revisores, ¿recuerdas que teníamos la cosa de los metadatos, que no me gustaba? En este caso, estamos cambiando 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 la 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. Así que entonces, ya sabes, no hay mapeo, no hay metadatos. Es todo lo que piensas de un grupo a la vez, y luego llenas lo que las personas que van dentro de él. Y dentro de eso tienes lo mismo que acabamos de ver. Tienes una visualización líder, que tiene un avatar, tienes el texto, tienes la descripción, nada, nada demasiado salvaje. Funciona bastante bien. Se compone muy bien, como que no tenemos que aprender nada nuevo. No había propiedades extra en el elemento. La única nueva API era para el grupo y todo está contenido en sí mismo. 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, teníamos estas dos descripciones. Una es en línea, una es en bloque. ¿Cómo encajamos estas? Bueno, simplemente ponemos dos descripciones, supongo. Así que tienes la descripción de la lista de acciones variante en línea y tenemos la descripción de la lista de acciones variante bloque. Y ambas simplemente se sientan una al lado de la otra y ya sabes, realmente no importa qué orden les des porque tenemos los slots y los slots tienen el espacio específico para entrar. Así que sí, 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. De nuevo, quería poner el título dentro porque ya sabes, React tiene una forma de poner hijos, pero para que se mantenga consistente con la API del grupo, seguí el título y la variante en lugar de ponerlo dentro. Pequeña, pequeña elección. Muy bien. Así que ahora si comparas, esto es lo que parecía en el grupo de metadatos en el anterior API de configuración donde tenías un grupo de metadatos, tenías que hacer coincidir con el ID del grupo, teníamos que hacer este escape hatch render para las descripciones. Y aquí, definitivamente, ya sabes, se ve mucho más largo, pero también es más componible. Así que, hemos podido tomar todas las partes sin romper la API y seguir componiendo ellas y funciona realmente bien. Muy bien. Así que, pasando de esto, veamos si las otras cosas funcionan. Así que, el hito es una visualización líder, pero también tiene este efecto genial donde puedes seleccionar algo, ¿sabes? Y esto ni siquiera lo hablamos en la, en realidad ya sabes qué, ahí tienes. Así que, ni siquiera hablamos de esto en la API de configuración porque bueno, ya no tenía espacio para ello. Pero en este caso, hay un montón de cosas que podrías hacer. Probablemente podrías mostrar la marca de verificación como un icono de verificación, ya sabes. Así que, si este hito está seleccionado, entonces pon un icono de verificación aquí. Pero también queremos que este espacio se abra, ¿verdad? Porque queremos que estos estén alineados. No queremos que estos dos estén alineados a la izquierda y luego no tengan espacio. Así que, esto no funciona. Necesitas saber que uno de los slots está lleno.

9. Selección de ActionList y Escalado de API

Short description:

Puede utilizar 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 apropiado en función de la variante de selección. La API basada en slots asegura que el componente sabe dónde renderizar la selección.

Entonces, quizás hagamos esto que hemos estado haciendo hasta ahora. Tienes action list dot check. Y luego pasas checks si está marcado como verdadero, entonces 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 los asignados. En el caso de los asignados, sin embargo, notarás que ya no es una verificación. Es una casilla de verificación porque es una selección múltiple, no solo una. Entonces, sabes, no queremos cerrar esto con una marca. En realidad queremos mantener esto abierto, poner todas las marcas de verificación. Entonces, quizás en lugar de check hagamos check box y luego se envía a. Más o menos. Pero creo que hay una forma más sencilla porque, para ser honesto, basado en 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. Entonces, voy a reemplazar esto con ActionList.selection. Y ActionList sabe qué selección poner en función de la variante de selección o quizás un nombre diferente para esto, ya sabes, selección única, selección múltiple. He elegido variante de selección donde puedes hacerla única y múltiple. Y en función de esto, el action select sabe qué estilo de selección renderizar, ¿verdad? Entonces se convierte en un poco 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. Entonces, pones 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 en función de la variante de selección. Entonces la API está escalando bien.

10. Componente del Menú de Acción y APIs Componibles

Short description:

Con el componente del menú de acción, puedes usar el menú de acción punto ancla para definir el elemento ancla. Todo lo demás que coloques dentro del componente se renderiza dentro de la superposición. 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 una entrada de texto dentro de la superposición y usar un divisor del menú de acción o un divisor de la lista de acciones para el comportamiento deseado. El componente de entrada de texto del menú de acción 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, proporcionando opciones de flexibilidad y personalización.

Y finalmente, realmente no hemos hablado de cómo se renderiza esto en el menú. Hasta ahora hemos estado mirando esto, el contenido interior. ¿Pero qué pasa con el menú de acción? ¿La superposición? ¿En qué haces clic para obtener esto? Eso no es una lista de acciones, es un componente diferente llamado menú de acción. Los nombres son similares porque queremos acoplarlos muchas veces. Así que déjame ver. Bueno, este no es el ejemplo. Así que con el menú de acción, lo que obtienes es un menú de acción punto ancla. Así que por ejemplo, estos tres puntos son un ancla para ese caso. Pero en este caso, todo esto es un ancla. Así que tienes asignados y tienes este engranaje, y toda la fila es un ancla. Así que básicamente puedes poner lo que quieras. Tengo asignados y engranajes y están alineados y demás. Pero aparte de eso, todo lo demás que pongo aquí se renderiza dentro de la superposición. Así que el menú de acción esencialmente va en contra de los slots, sabe lo que es un ancla, sabe todo lo demás depende de ti. Así que podrías poner un menú, podrías 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 en la superposición. ¿Y qué pasa con este patrón que ves a veces 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 verdadero, y luego renderizaría la entrada. Tendrías que darle este marcador de posición, encontrar un usuario, tendrías que decir qué pasa cuando cambia. Así que estás mirando un montón de variables de configuración, un montón de lista de nuevas propiedades que serían añadidas a la API de nivel superior. En este caso, creo que podemos salir del paso con renderizar una entrada de texto. Si lo renderizas aquí en el área abierta, irá dentro de la superposición. ¿Verdad? Ve dentro del cuerpo de ella, y justo antes de la lista de acciones, y puedes añadir un menú de acción divisor o un divisor de la lista de acciones, son más o menos lo mismo para obtener este comportamiento. Y porque queremos algunos estilos de enfoque, como mira esto. Si estoy seleccionando, puedo mover mi teclado alrededor, pero mi estado de selección todavía permanecerá aquí para que pueda seguir escribiendo. Este comportamiento es muy específico. Así que para hacer eso, en realidad enviamos menú de acción punto entrada de texto. Y esto es como, renderiza el texto y renderiza el divisor. Renderiza todo el comportamiento, pero entonces 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, encuentra un usuario. Y luego en la cadena, dices, filtra 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 perfecto sentido. Así que este es solo un ejemplo de cómo puedes usar las APIs Componibles para componer componentes del producto y componer componentes de la component library, ponerlos todos juntos. Y de alguna manera todavía funciona, porque hemos pensado en todos esos casos de uso donde no realmente sabemos qué pondrán las personas aquí, pero sabemos que quieren poner cosas en la superposición. Así que les damos ese slot, que es una especie de slot abierto, y puedes llenarlo con las cosas que quieras.

11. Flexibilidad y Construcción para las Personas

Short description:

Experimenta para encontrar tu lugar 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 sobre 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.

Bien. Veamos. Entonces, para resumir, experimenta para encontrar tu lugar en ese espectro de flexibilidad y consistencia, ¿verdad? Como que alguien más realmente no puede decirte eso. Tienes que conocer la cultura de tu empresa. Tienes que conocer el tipo de casos de uso que atiendes. En nuestro caso, pensé que estábamos más en el lado de la consistencia, pero en realidad en muchos casos, tenemos que ser, GitHub es lo suficientemente grande para ser, ya sabes, como, hay muchos casos de uso. Así que probablemente nos inclinamos un poco más hacia el tamaño componible, más flexible. Pero aún puedes usar la composición para permitir flexibilidad sin expulsar, ¿verdad? Y lo que me lleva al último punto, como los sistemas de diseño son para las personas, las bibliotecas de componentes son para las personas. Brillante cita. Me encanta esto. Esto es de Gina. Y el resumen es que las personas que usan nuestros componentes simplemente están tratando de construir los productos, ¿verdad? Están tratando de construir productos para sus clientes. No están tan interesados en lo que es la API o no están muy 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 lo que 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 como 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 que todavía tienen que hacerlo, hay trabajos que hacer. Esa es la idea. Experimenta para saber dónde estás en el espectro, usa la composición en lugar de expulsar de los sistemas. Y finalmente, recuerda que estás construyendo para las personas. Gracias. Eso es todo. Si quieres echar un vistazo a Primer. Si quieres echar un vistazo al 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 adiós.

QnA

Sesión de Preguntas y Respuestas

Short description:

Estoy bien. ¿Cómo estás? Bien. Bien. Me encantó la charla. Una de las primeras preguntas es sobre decidir si un componente debe ser parte del sistema de diseño basado en su uso. Otra pregunta es cómo decidir si un componente debe dividirse para soportar diferentes casos de uso sin hacer que la API sea demasiado compleja. Lidiar con las 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 utilizar una biblioteca de componentes depende del nivel de personalización requerido y la etapa del proyecto. Finalmente, hay una pregunta sobre los libros coordinados por colores en el fondo.

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

Una de las primeras es, en resumen, ¿existe una regla general para decidir si un componente debería ser parte del sistema de design? ¿Cuántas veces necesitas usarlo? ¿Existe un número de usos suficiente para que tomes esa decisión? Esa es una muy buena pregunta. Así que supongo que la regla general es algo que insinuaste, que es cuántas veces se usa, especialmente en diferentes páginas y productos. Así que 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 en todos los equipos y productos, sería solo un poco inconsistente o podría ser accesible en uno pero no en el otro. Así que eso es generalmente una señal segura de que esto podría ponerse en el sistema, pulirse, hacerse consistente y luego liberarse de nuevo a los equipos para usar esa única versión verdadera. Eso es genial. Gracias.

Y una cosa que realmente me encantó mientras avanzabas en la charla fue que estabas construyendo lentamente y vimos este sistema de design volverse cada vez más complejo. Y hay una pregunta relevante a esto donde alguien pregunta cómo decides si un componente debe dividirse en varios componentes para soportar diferentes casos de uso sin que la API se vuelva demasiado compleja? Sí, esa es una buena pregunta de nuevo. No sé si hay una respuesta fácil para ello más allá de que estás tratando de construir algunos ejemplos con ello y puedes, como lo intenté hacer en la charla, puedes empezar a notar cuando empieza a ser incómodo de usar. Cuando empieza a ser un poco demasiado, tienes que hacer demasiado trabajo de adivinación o copiar de los docs exactamente. Así que cuando ya no es predecible, usas la API, realmente no puedes decir qué va a pasar. Esa es generalmente una señal de que este componente está haciendo demasiado y podrías beneficiarte de un componente especializado o la API simplemente está yendo 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, así que puedes hacer más manteniendo la API más pequeña. Gracias.

Y otra también, porque siempre habrá excepciones de design. Cuando estás tratando de lidiar con esas, ¿los patrones compuestos son la única manera de ser lo suficientemente flexible pero aún así mantenerse abstracto? Al menos en mi experiencia, esa es la forma que más me gusta. Algunas personas también tienen estilos anidados, así que básicamente lo pasas a la raíz, y puedes referenciar a cada hijo y personalizarlos. Así que tal vez en la lista de nivel superior, puedo decir que todas las imágenes, en realidad deberían tener este borde extra, porque yo así lo decidí. Pero me gusta colocarlos juntos, ¿verdad? Tan cerca como pueda de ellos. Así que generalmente prefiero compuesto, pero es CSS. Puedes empezar desde arriba y hacerlo cascada hacia abajo. Genial. Y otra cosa en la que quiero obtener tu opinión, ¿cuál es tu punto de vista sobre crear tu propio sistema de design versus usar una biblioteca de componentes? Sé, como dijiste, que depende. Pero ¿cómo sueles tomar esa decisión? En realidad no tengo una buena respuesta, así que voy a dar la respuesta que yo personalmente doy. Que es que puedes empezar con una biblioteca, que espero que sea una sin estilo. Ahora hay unas pocas. Para eso, al menos puedes controlar el estilo, pero eventualmente siempre llego a un punto donde quiero personalizarlo más y tengo que entrar en lo interno. Así que en el momento en que te encuentras personalizando el comportamiento y no solo la estética de ello, esa es una señal de que tienes que sacar este componente y construirlo desde cero. Hazlo tuyo. Pero honestamente, si miras una component library y dices, estamos contentos con el comportamiento que este componente nos da, especialmente si estás en una etapa temprana, no tienes que conseguir todo exactamente como quieres. Y eres un poco más flexible. Enviar es más importante que... Es mi opinión, creo. Entonces, claro, usa una component library. Trata de encontrar una sin estilo, porque al menos quieres que se sienta como tu propia empresa. No quieres que se sienta como la de alguien más. Y nos hemos quedado sin tiempo, pero quiero poner una pregunta más para ti. ¿Coordinaste deliberadamente los colores de 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 pueda seguir decodificando. Genial. Lo puse allí porque hace que la transición sea más suave. Eso es genial. Muchas gracias Sid. ¡Todos aplaudan a Sid, déjenle oírles!

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

Don't Solve Problems, Eliminate Them
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.
Using useEffect Effectively
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 Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
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
TypeScript and React: Secrets of a Happy Marriage
React Advanced Conference 2022React Advanced Conference 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
TypeScript and React are inseparable. What's the secret to their successful union? Quite a lot of surprisingly strange code. Learn why useRef always feels weird, how to wrangle generics in custom hooks, and how union types can transform your components.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
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.
Principles for Scaling Frontend Application Development
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
Top Content
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 Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
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.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
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
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- 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
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
Top Content
WorkshopFree
Sam Sycamore
Siriwat (Jun) Kunaporn
2 authors
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