Caminando en la línea entre la flexibilidad y la consistencia en las bibliotecas de componentes

Entonces, vamos allá. Soy Sid. Trabajo en el equipo del sistema de diseño en GitHub y soy uno de los mantenedores de Primer, que es la biblioteca de componentes React que otros equipos en GitHub utilizan para construir las cosas que realmente te gusta usar.

Antes de comenzar, quiero dar una advertencia. GitHub ahora es parte de Microsoft, así que tengo que decir esto, estas opiniones son mías y no de mi empleador todavía. Estoy tratando de cambiarlas, estoy trabajando en ello. No he estado allí el tiempo suficiente, así que dame un tiempo. Muy bien.

Entonces hablemos de la consistencia y flexibilidad cuando se trata de bibliotecas de componentes. Lo que sucede con las bibliotecas de componentes es que no hay una única respuesta verdadera, y realmente depende de un montón de contexto. Así que cuando empecé, comencé a mirar otras bibliotecas de componentes, eso es lo suficientemente grande. Miré Polaris, que es el sistema de diseño de Shopify, y miré Material UI, que es una biblioteca de componentes de código abierto, y este es un componente que ambos tienen, como Así que con Polaris, cómo creas este banner es diciendo que quieres un banner. El estado de este banner es crítico. Y aquí está el título. Y se renderiza todo eso. El icono está ahí. El botón de cruz está ahí. Todo eso está ahí. Y si quieres agregar una acción, dices objeto de acción donde dices que este es el contenido, y si se hace clic en esto, esta es la función que debes llamar. Muy, muy descriptivo. Hay mucha configuración aquí. Si tengo que construir lo mismo con Material UI, se vería algo así. Tengo una alerta. No lo llaman banner, lo llaman alerta. No importa. Y le das una gravedad de error. Y luego puedes pasarle un icono. Puede ser cualquier icono. No tiene que ser este icono. Básicamente puedes dar cualquier icono.

Es muy flexible. Y también te permite sobrescribir parte del CSS. De hecho, puedo cambiar el color del borde aquí, como lo he hecho. Y finalmente... Ay. Bien. Finalmente, si quiero agregar contenido dentro de él, hay un título de alerta. Pero si quiero un botón, puedo traer mi propio botón y ponerlo allí. Y luego soy responsable de este margen que ves aquí. Bien.

Entonces, si comparas estas dos APIs de componentes, están creando el mismo componente, pero hay mucha diferencia en cómo se ve la API y cuánta flexibilidad tienes. Y eso me lleva al espectro de flexibilidad. Entonces, cuando pienso en Shopify como Polaris, creo que Polaris está en algún lugar aquí, donde es muy opinativo, tiene una API extremadamente estricta y eso lleva a estos resultados predecibles, consistentes. Puedes usar la alerta donde quieras y obtendrás algo similar. Pero, por supuesto, puede volverse un poco rígido y restrictivo si estás experimentando con él. Por otro lado, Material UI está probablemente aquí. Es de código abierto, por lo que no hay suposición de contexto. Tiene que tener una API muy flexible, porque el equipo de Material no puede adivinar realmente para qué lo usarás. Lo que significa que depende de tu empresa, tu contexto. Y si no tienes cuidado, si usas Material UI como tu sistema de diseño, puede volverse desordenado o fragmentado o simplemente necesitas muchas barreras de protección en su lugar.

Entonces, cuando estaba mirando Primer React, pensé, bueno, ¿dónde nos ubicamos? ¿O si estás pensando en ello para tu biblioteca de componentes? La respuesta, por supuesto, siempre es depende. Y también depende de estos factores. ¿Está construido para un producto específico o es de código abierto? ¿La decisión de diseño está centralizada porque tienes un cierto equipo de diseño o los productos individuales tienen su propio equipo de diseño? ¿Está disperso? ¿Cuánto tiempo tiene el producto? ¿Qué tan maduros están los patrones? Si ya tienes patrones establecidos, es más fácil ser más consistente, en comparación con Si aún estás encontrando los patrones, es mejor ser más flexible. Y miré esto y pensé, construimos para un producto específico. Tenemos un equipo de diseño centralizado. Hemos establecido patrones. Entonces GitHub es muy antiguo. Entonces probablemente aquí, así es cuánta flexibilidad probablemente deberíamos permitir. Para mostrar esto, miré este componente. Este es un patrón común que has visto en muchos lugares.

Lo que quiero que te enfoques es solo en esta parte, la lista de personas. Y llamamos a esto una lista de acciones porque es una lista. Y puedes realizar una acción. Soy muy inteligente. Entonces, este patrón se utiliza en varios lugares. Esta es una lista de usuarios que acabo de mostrarte. Pero en muchos de estos lugares, todas son listas de acciones que se distribuyen, a veces en un menú, a veces no.

Entonces, para construir esto, miré este ejemplo más simple. Pensé, bueno, esto parece fácil. Esta es una lista de elementos. Puedes hacer clic en ellos, y eso es una acción. Entonces dije, está bien, es una lista de acciones. Toma un array de elementos, porque quiero que sea una API muy restrictiva, así que fui con un enfoque de estilo de configuración. Y si quieres seleccionar algo, entonces puedes hacer clic en él, y te devolveré el elemento que pasaste para que puedas averiguar qué hacer. Es un poco incómodo, porque esto se basa en texto. Así que lo cambié un poco. Ahora es un objeto. Entonces tienes texto, y luego puedes hacer una selección. Esto es lo que se activa, ¿verdad? API de configuración. Luego, a continuación, miré estos divisores. Tiene sentido. Quieres dividir tus opciones por contexto, así que si quieres agregar un divisor aquí, ¿qué texto tendría? ¿Simplemente dices que es un divisor, o tenemos un código secreto donde, si dices guion bajo divisor, es una cadena mágica. Tal vez sea un tipo de divisor. No hay una forma fácil de hacerlo, así que lo que decidí fue en lugar de depender de cadenas mágicas, vamos a incorporar esto en el componente. Porque los componentes de React son funciones o funciones de JavaScript al final del día, siempre puedes adjuntarles más atributos. Así que básicamente aquí estoy adjuntando otra clave, que es divisor, y internamente podemos cambiar esto. Internamente es una cadena mágica, pero para los usuarios de nuestros componentes, dirán lista de acciones o divisor. Hasta ahora, todo bien. Ahora, veamos esta etiqueta.

Entonces es la misma lista. Probablemente estés haciendo un bucle en algún lugar como repo.labels. Y el texto y el onSelect tienen sentido. El texto está ahí. Pero luego tenemos este círculo que mostramos para los colores. Entonces tal vez sea el color de la etiqueta y el componente de lista de acciones es lo suficientemente inteligente como para saber que si pasas color de etiqueta, entonces sabe que tiene que representar un pequeño círculo allí. Eso tiene sentido. Pero ¿qué pasa con este, assignEv? Entonces el texto y onSelect siguen bien, pasas el texto. Pero tal vez pases un avatar y, de nuevo, es lo suficientemente inteligente como para saber que si pasas avatar, entonces tiene que representar una pequeña imagen con la URL pasada. Buen trabajo. Pero por supuesto, hay más. Hay hitos y proyectos. Aquí hay un icono. Supongo que simplemente agregamos una prop de icono de nuevo. Y si es un icono, es lo suficientemente inteligente como para saber dónde representar el icono y qué tamaño tiene. Pero aquí es donde empieza a complicarse. Pero ¿qué pasa si alguien pasa tanto un icono como un avatar? No estoy diciendo que alguien esté tratando de romper mi componente, pero tiene sentido. Si alguien está tratando de crear un estado de selección, probablemente lo haría de esta manera. Pero por supuesto, lo arruina un poco porque en realidad no queremos que la selección sea de esta manera. Hay una forma diferente de hacerlo. Pero la API te ha confundido un poco. Así que cambiamos y dijimos que se permite un único elemento en el prefijo. Lo llamaremos elemento de prefijo. Puedes pasar el componente y puedes pasar qué props toma. Cada vez que veas algo como esto, que es como aquí está el elemento, aquí están las props, es un componente. Tal vez deberíamos llamarlo prefijo y aceptar el componente. Hemos abierto un poco la API. Como dije, las personas no están tratando de romper el componente. Las personas están tratando de construir lo que tienen que hacer y luego irse a casa. Así que componente de prefijo.

No lo llamamos prefijo, lo llamamos visual principal. Entonces esto funciona de alguna manera. Puedes tener un avatar, puedes tener un componente de color de etiqueta que puedes colocar allí, puedes tener un icono de hito. Así que funciona de alguna manera. La API parece un poco complicada porque el texto es un texto. Supongo que esto es una cadena. Luego, onSelect es una función y el visual principal es un componente renderizado. Es JSX. Entonces la API es un poco, como que no puedes adivinar todo esto si miras la docs sabes qué hacer.

De acuerdo, sigamos adelante. Hay una descripción. Mostramos el nombre aquí. Así que agregué un campo de descripción. Pero en las etiquetas, porque las descripciones de las etiquetas pueden ser muy largas, quieres que estén en la línea siguiente. Así que tal vez eso sea como una descripción, descripción de etiqueta pero luego una variante de descripción porque la descripción puede ser en línea o en bloque. Supongo que funciona. Esto también comienza a parecer un componente pero nos ocuparemos de eso más tarde.

Y luego el jefe final de esto es este componente. Que tiene grupos, porque luego quieres asignar un revisor, te mostramos estas son las suggestions y esto es todos los demás. Entonces la forma de hacer esto sería agregar una prop de grupo, ¿verdad? Otra prop, ¿por qué no? Y luego si el usuario ha editado recientemente, entonces dices suggestions, de lo contrario es todos los demás. Pero ¿cómo decides cuál se muestra primero? ¿Las suggestions se muestran primero o todos los demás? Así que tienes que darme un orden. Entonces hay otra prop llamada orden de grupo. Eso es un array, pero luego tenemos esta variación. En algunos lugares, queremos rellenarlo, así que necesito otra cosa llamada variante de grupo, supongo. Así que esto se convierte en una configuración, este título, esta variante. Y lo bueno de esto es que ahora tengo un objeto, lo que significa que puedo agregar un ID, para que al menos pueda decir que es el ID, como grupo uno o grupo dos. Y luego, ¿notaste que hay dos descripciones aquí? Hay una en línea y una en bloque. Así que supongo que vamos a hacer tal vez solo un array de descripciones, y luego cuál es en línea, cuál es en bloque, así que tal vez haya un array de variantes de descripción. Esto parece estúpido porque hay dos de ellas, así que tal vez sea un array de objetos. Y así es como va.

Entonces, lo único bueno de esto es que es muy fácil de escribir. Si escribes TypeScript, entonces es un objeto, es muy basado en configuración, puedes escribir todo el objeto. Pero lo que terminó sucediendo fue que la gente quería poner un icono aquí, poner un contador aquí en el lado derecho. Al final, esto es cómo comenzó a verse la API, donde había una prop render item. Es una render prop, es una inversión de control, te pasamos las props del elemento y te decimos, por favor, pásalas a lo que vas a renderizar aquí. Debido a que hay preocupaciones de accesibilidad aquí, hay mucha magia que sucede para el enfoque y la navegación por teclado, queremos que todo eso funcione, y te pedimos que lo devuelvas. Realmente tengo miedo de algo como render item, porque perdemos todo el control o todas las características en las que confiamos y confiamos en el usuario para asegurarse de que todo ese código azul para el diseño receptivo, la accesibilidad, lo hayan configurado correctamente y lo pasen hacia abajo, ¿verdad? Odio esto. Y especialmente este último patrón de render item, el problema con eso no es que la gente cometa errores, aunque sucede, no es como si la gente intentara romperlo. La idea es simplemente que el componente se volvió tan complicado con todas las props que en algún momento tuvimos que declarar la bancarrota de props y decir, aquí tienes una función, hazlo. No me importa. Y eso es como expulsar de un componente, lo cual desafía todo el propósito. Todo eso es en realidad un síntoma de no entender cuán flexible queríamos que fuera realmente el componente, porque si no queríamos tantas variaciones, probablemente aún podría funcionar, pero aprendí que probablemente estemos más abajo aquí, aunque tengamos todas las cosas que dije, depende. Pero GitHub es lo suficientemente grande como para que haya tantos contextos donde el mismo componente puede aparecer. Y cambia de un componente a otro. Así que intentemos esto de nuevo con una API ligeramente más flexible en mente.

De acuerdo, la respuesta que elegí es, intentemos la composición. Intentemos hacer un componente compuesto. Entonces hay una lista de acciones, como antes, pero en lugar de recibir una matriz de elementos, acepta un hijo, que es lista de acciones.item. Y .item sabe cómo renderizar las cosas de la misma manera. Y como antes, puedes adjuntar más componentes a un componente, porque al final del día, todo son funciones. Así que puedo decir, aquí hay un elemento, y luego lista de acciones.item es ese componente, y luego la gente puede usar esta agradable API compuesta. Lo bueno es que onSelect ya está en el propio elemento. Probablemente aquí adivinarías agregarlo también cuando seleccionas un elemento, colocas el onSelect o el onClick en él, así que tiene sentido. Y luego tienes todos estos elementos. Realmente me gusta esto hasta ahora, porque tiene sentido. Se ve pequeño. No es muy confuso. Siguiente paso, separadores. Si tuvieras que adivinar cómo se vería el separador, ¿qué adivinarías? De acuerdo, tres segundos. Uno, dos, tres.

Esa es una buena respuesta. Lo hicimos antes donde teníamos todo este código para el separador. Ahora es simplemente action list.divider, porque tenemos la opción de crear componentes y agregarlos a la lista de acciones. Y cuando decimos action list a divider, sabe cómo renderizarlo. Ya tiene la accesibilidad resuelta. Perfecto.

Muy bien, siguiente. Permíteme abrir las etiquetas. Así es como lo hicimos antes, donde había un componente visual líder. Me gusta esto. No quiero cambiar mucho. Solo agregaré un action list.leadingVisual. Y este componente visual líder sabe dónde renderizar esto, lo que sea que se coloque dentro. Así que puedes decir que este es el color de la etiqueta y esta es el área reservada para el componente visual líder. Si hay un componente visual líder, entonces desplaza el texto, maneja el margen, el espaciado, el tamaño, todo eso. Prácticamente te da un espacio, si lo piensas. Puedes llenar el espacio con el color de la etiqueta o un avatar, como este. Así que si piensas en estas dos APIs, la estructura básica sigue siendo la misma. Solo estás cambiando los espacios interiores, como el texto del componente visual líder. Eso es bastante bueno. Si puedes construir múltiples interfaces de usuario con la misma API, tendrás que aprender menos y podrás completar tu tarea más rápido y regresar a casa más rápido, lo cual es una victoria para todos.

Muy bien. Ahora veamos estas descripciones. Antes, teníamos una clave aquí, etiquetada como nuestra descripción. Voy a hacer el mismo comportamiento de espacio. Tenemos un action list o descripción. Y puedes colocar esta descripción justo aquí, lo que sea que escribas dentro va a esta área de descripción. Ahora, si tuviera que hacer una variante de bloque versus en línea, ¿dónde colocarías esta propiedad de variante? Probablemente la colocaría aquí. Porque esto es la descripción y aquí es donde va la descripción. Así que voy a colocar una variante de bloque aquí, que hará esto.

Entonces, muchas de estas APIs se vuelven más fáciles de adivinar cuando quieres una variante en la descripción. ¿Dónde lo colocas? Lo colocas en la lista de acciones o en la descripción. Tiene sentido.

Muy bien. Sigamos adelante. Muy bien, rápido. Me estoy quedando sorprendentemente sin tiempo, así que voy a explicar rápidamente cómo funciona la implementación de las ranuras. Hay un objeto de ranura dentro del elemento. Y luego recorremos los hijos. Así que digo, react children.forEach. Esto es como una API de nivel superior de React. Y mientras recorro el hijo, mientras recorro los hijos, verifico cuál es el tipo del hijo. Y lo divertido es que todo este JSX se convierte en React.createElement. Y el tipo es la función que es similar al componente. Así que si realmente miro child.type, va a ser uno de estos, donde va a ser actionList.leadingVisual o actionList.description. Así que puedo simplemente verificar si child.type es actionList.leadingVisual. Y simplemente voy a secuestrar ese hijo y luego ponerlo en una ranura. Eso suena tan mal. Voy a llenar la ranura de leadingVisual con este hijo. Y hice lo mismo con description. Y también puedo verificar las props del hijo. Así que puedo decir si child.props.variant es block, entonces slots.blockDescription. De lo contrario, slots.inlineDescription. Y si no es ninguno de estos, entonces sé que está en la forma libre, el campo de texto aquí. Así que digo slots.freeform.pushChild. Veo algunas cejas levantadas.

Justo, justo. Debes recordar que esta API solo funcionará cuando tengas control total o puedas esperar lo que vendrá dentro de los hijos. Entonces, en este caso, con action list.item, estas son las únicas cosas que puedes poner. Puedes usar action list.readingVisual, description o simplemente texto. Si quisieras poner cualquier otra cosa, no funcionaría porque simplemente iría en la ranura de forma libre y no lo identificaríamos. Y puedes salirte con la tuya con optimizaciones y APIs agradables como esta, o simplemente llamémoslo lo que es, puedes hacer trucos de secuestro de hijos, si controlas la API.

Y como esto no es una configuración de component library, controlamos cómo se ve la API. Y nuevamente, la gente no está tratando realmente de romper los componentes, la gente está tratando de hacer el trabajo y volver a casa. Así que si es una API predecible, haz todos los trucos que quieras. Tienes mi permiso si importa.

De acuerdo. Echemos un vistazo rápido al hito. Icono de proyectos. No sé si eso aún funciona. Porque, ya sabes, simplemente llenamos las mismas ranuras. Y finalmente, veamos a este chico grande. Aquí tenemos grupos. Entonces, nuevamente, si tuvieras que adivinar cuál sería la sintaxis para el grupo, ¿qué adivinarías? De acuerdo. Estoy tan decepcionado. Pero está bien. Tal vez no sea tan obvio como pensaba. Va a ser action list.group. Porque luego puedes poner dos grupos, el grupo espera un título y puedes personalizarlo con la variante, de la misma manera que lo haces con description. Y luego dentro de ellos, simplemente estás poniendo action list.items. Y todo esto es similar. Es solo leading visual description. Pero es muy intuitivo cómo puedes, si puedes hacer esto, puedes crear una gran cantidad de UI en GitHub, lo cual es bueno.

Y finalmente, si quisieras ambas descripciones, simplemente colocas dos action list descriptions, una con la variante inline y otra con la variante block. Entonces, ambas identificarán la ranura que deben llenar, llenarán esas ranuras y se renderizarán en los lugares correctos. Sin errores.

Quiero decir, es un error, pero no lo vemos. De acuerdo, finalmente, estoy corto de tiempo, así que voy a omitir esto, porque es un poco aburrido.

De acuerdo, finalmente, déjame decir esto. Tienes que experimentar para encontrar tu lugar en el espectro de flexibilidad y consistencia. Pensé que sabía dónde estábamos en el espectro. Estaba claramente equivocado, así que tienes que jugar un poco con ello y encontrar tu lugar. Utiliza la composición para permitir la flexibilidad cuando sea necesario, en lugar de expulsar. Entonces, como, renderizar. La inversión de control es buena cuando no tienes ningún control, pero en muchos casos, tienes suposiciones o puedes predecir lo que las personas quieren hacer. Así que composición en lugar de expulsión.

Y finalmente, los sistemas de diseño y las bibliotecas de componentes están diseñados para las personas. Así que las personas no están tratando realmente de romper tu API. Creo que eso es una preocupación que tenemos mucho. Pensamos, no, las personas lo usarán de esta manera, ¿y qué pasará entonces? Las personas no están tratando de hacernos quedar mal. Solo están tratando de obtener el resultado correcto y tienen algo en mente y quieren seguir adelante. Así que si puedes crear APIs predecibles, incluso si implica cometer errores, está bien.

Muchas gracias. Eso es todo lo que tengo. Si quieres ver las diapositivas, están en esta URL. Y si quieres más malas ideas, puedes seguirme en Twitter. Gracias. Gracias, gracias. Muchas gracias, Sid. Me encanta Chi. ¿Podrías venir aquí? Podemos reunirnos en este bonito logo de React que me encanta aquí. ¿Cómo estás? ¿Cómo te fue en la charla? Bien. Bien, bien. Entonces, gente, en caso de que tengan algunas preguntas y aún no las hayan hecho en Slido, asegúrense de revisar Slido y hacer esas preguntas. Vamos directo a ello. Tenemos una de ellas...

Tenemos a Nicola que hizo una pregunta, ¿por qué no abordarlo, como construir una API más flexible a un nivel más bajo de abstracción, y luego construir una API con opiniones como una capa superior. Eso es un buen punto. De alguna manera hacemos eso. Muchas de las visualizaciones y descripciones líderes se construyen sobre APIs de nivel inferior. Así que hay como un avatar, y hay como un campo de texto. Entonces, si quisieras, podrías tomar los bloques de nivel inferior y construirlo tú mismo. Creo que eso también es una forma de expulsión, porque creo que se menciona mucho donde si no te gusta la API con opiniones, simplemente constrúyela tú mismo con los bloques de construcción de nivel inferior, pero luego te pierdes todas las accessibility y responsividad... Hay mucho code de pegamento que se esconde debajo del componente y que simplemente abandonas. Así que puedes hacerlo si quieres, pero siempre es agradable cuando no tienes que bajar a un nivel inferior.

Y esta siguiente pregunta que ha saltado al principio es una que también estaba pensando. ¿Es posible escribir un tstype para permitir solo actionlists o XXX como hijo de actionlists? Sí, lo es. Tenemos tipos para esto. Es de código abierto, si vas a GitHub slash Primer slash React, puedes encontrar slots. Estoy muy orgulloso... Me llevó una semana entera obtener los tipos correctos. Pero finalmente lo conseguí, y sí, puedes escribirlo y si das algo más, entonces muestra las líneas onduladas.

Bueno, bueno. Esta es una pregunta. Estaba pensando en... Me encanta cómo la audiencia lee mi mente. ¿Qué herramienta increíble usaste para crear esas diapositivas? Porque la necesito en mi vida. Al igual que la mayoría del code que escribo, también son como crímenes y trucos. Bueno, esto va a ser molesto. Lamento decepcionarte, pero no hay ninguna herramienta. Es solo una vista previa a la izquierda, que es solo una lista de componentes que están a continuación. A la derecha, es solo code. Y ya he escrito previamente el code, solo lo siguiente, siguiente con él. Pero como es un área de texto, puedo fingir que estoy escribiendo y que está haciendo algo. No está haciendo nada. Son solo diapositivas.

Solo estoy yendo siguiente, siguiente, siguiente. Bueno. Fingiéndolo hasta lograrlo. Lo sé, ¿verdad? Delitos directos. Y también, como dijiste, los desarrolladores a veces... No nos gusta seguir las reglas todo el tiempo. Entonces, ¿cómo presentas a los consumidores de la component library que solo usen hijos válidos en lugar de solo divs aleatorios y tomar el control?

Sí. Los tipos ayudan. Pero podrías hacer un TS, ignorarlo y seguir con tu vida. No podemos detenerte. Muchas veces esto no se trata solo del code, sino de la colaboración. Así que estamos constantemente buscando... Siempre estoy buscando quién está usando ActionList. Y si lo están usando de formas que no había previsto, probablemente significa que tienen un patrón que no había pensado, o un patrón que no encaja en la API. Así que desafortunadamente, la respuesta es, tienes que hablar con ellos y tienes que descubrir lo que quieren.

Cómo se atreve la respuesta a ser hablar. ¿Y cómo implementarías este filtrado en el propio componente ActionList? Esa es una buena idea. Esa fue una diapositiva que me salté. Porque eres responsable de recorrer los elementos. Te damos un campo de texto, que se renderiza en el lugar correcto. Tiene el margen correcto, tiene un cargador, y todo eso. Pero la lógica real de lo que sucede cuando alguien escribe se pasa al usuario. Así que nos das usuarios filtrados, y nosotros los renderizamos. Y si hay una pulsación de tecla, entonces cambias los usuarios filtrados. ¿Y para qué necesitábamos los slots? Los slots son perfectos para lugares donde tienes un componente con opiniones. También tienes solo una pequeña cantidad de flexibilidad. Como en este caso, siempre se ve igual, pero la visualización principal podría ser cualquier cosa. Podría ser una etiqueta, podría ser un icono, podría ser un avatar, podría ser algo más, pero el tamaño y el espaciado ya están controlados. Entonces, los slots son geniales para pequeñas cantidades de flexibilidad que quieres agregar sin tener que rehacer todo el componente. Y la siguiente pregunta sobre integraciones de refs, como Material UI, ¿cómo trabajarías con eso? Ref hacia adelante todo el camino, así que la visualización principal reenvía la ref, el elemento reenvía la ref, la descripción reenvía la ref.

No hay una forma sencilla de hacerlo. Simplemente tienes que reenviar la ref hasta el final.

Y esta última pregunta, porque veo que se nos ha acabado el tiempo. ¿Cómo te aseguras de que nada se rompa desde una perspectiva de CSS cuando estás construyendo una API multipropósito? Esa es una buena pregunta. Así que quiero decir que al menos en este componente, los slots han ayudado mucho porque los slots, parecen simples, pero son bastante restrictivos. Hay un ancho máximo y un alto máximo y un margen. Y hay una pequeña diferencia en píxeles entre el color de una etiqueta y un avatar. Y para eso, hay un ancho mínimo, ancho máximo en funcionamiento. Así que hemos intentado construir todos los casos de uso que la gente podría usarlo y luego hemos incorporado muchas restricciones en el CSS para que no se salga.

Genial. Muchas gracias Sidd. Nos vemos. Todos aplaudan. Gracias a todos. Aplaudan. Muchas gracias. Que tengan un buen día, todos. Gracias.