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

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.

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.

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.

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.

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.

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...

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.

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.

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.

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.

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.

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!