Fuera con sus cabezas: El auge de los componentes sin cabeza

Soy Omri, soy el CTO de Kodaks. Kodaks es una empresa de Wix que construye herramientas increíbles para desarrolladores, y voy a hablar sobre los Componentes Headless. Qué son. Por qué deberías preocuparte. Cómo utilizarlos de la mejor manera. Vamos a repasar algunas opciones populares y verlo en ejemplos y, por supuesto, voy a compartir nuestra experiencia en Kodaks.

La razón por la que elegí este tema es que veo una gran oportunidad aquí para aprovechar una brecha en el mercado de una manera que nos ayude a todos. Sin vergüenza, Kodaks está disponible, es gratuito, es una versión beta abierta desde Navidad. Puedes seguirlo en el enlace de GitHub. Si estás usando una computadora de escritorio, es un IDE, no es realmente para teléfonos. La forma en que funciona es que puedes editar los componentes react visualmente y de forma aislada, y es una excelente, y muy efectiva forma de editar tus componentes.

Los componentes son geniales, por eso todos los usamos. Pero nos pagan por construir aplicaciones, ¿verdad? Los componentes son solo una forma muy eficiente de hacer eso. Por cierto, esta es la única referencia a la IA, así que mi regalo para ti es como diez minutos sin IA. Volviendo a nuestra aplicación, queremos construir algo como un clon de Google Docs y hay mucho trabajo. En ese trabajo, está esta cosa del menú. Es un menú bastante básico. Y si somos muy ingenuos, podríamos decir algo como, ¿qué tan difícil puede ser, verdad? Es HTML y CSS es trivial. Tiene estados abiertos y cerrados, un montón de elementos. Los elementos se hacen clic, fin del problema. Excepto por algunos comportamientos secundarios como pequeñas cosas, como, ya sabes, z-indexing, accessibility, redimensionamiento, pellizcar, desplazamiento, enfoque, navegación por teclado. Bueno, en realidad es mucho trabajo. Y esto ni siquiera es algo que esté en la especificación, ¿verdad? Esto es solo algo que debemos hacer para lanzar productos de calidad. Y supongo que esa es la razón por la que muchos de nosotros usamos bibliotecas de componentes. Ya sea que construyas la tuya propia a lo largo de los años, que la lleves de un proyecto al siguiente. O uses una de código abierto o comercialmente disponible. Tenemos Material UI, Ant Design. Es un gran espectro. Algunas de ellas son realmente buenas. Todas tienen la misma premisa.

Los desarrolladores hablan y podrás desarrollar una interfaz de usuario atractiva muy rápidamente. Y los buenos realmente cumplen con eso. Pero hay un problema con todos ellos, ¿verdad? Lo llamo el muro de personalización. Y te estrellas contra él bastante tarde en el proyecto cuando descubres que tu tabla y tu selección múltiple no se sienten o no se ven iguales.

Y aquí está la anatomía del muro de personalización. Prometes a tu gerente de producto una lógica empresarial personalizada accesible a través de un diseño hermoso y único. Y tu diseño y la biblioteca de componentes que elijas están teniendo una pelea. Y si trabajas como yo, esto es especialmente frustrante porque lo ves muy tarde en el juego, porque me gusta construir una interfaz de usuario rápida para transmitir el punto de la lógica empresarial al cliente, hacer algunas iteraciones y luego hacer los ajustes finales solo en las características que realmente se enviarán.

Así que, solo por mostrar de manos, estamos aquí estrellados contra este muro de personalización. Muy bien. Para los pocos afortunados que no levantaron la mano, permítanme mostrarles un ejemplo. Y voy a usar Codex para mostrar los ejemplos. Este es nuestro IDE y este es el comportamiento esperado. Este menú es de AntDesign. Es una biblioteca de componentes realmente buena. Es altamente personalizable. Y lo que podemos ver aquí es que el menú tiene un submenú y los elementos se pueden agrupar. Y mi diseño requiere un ícono en el grupo A. Vamos a reciclar este ícono aquí. Así que déjame tomarlo. Y este es el dato que genera el menú. Solo voy a copiar y pegar. Perfecto. Y ya vemos que hay un problema. La estructura de datos no acepta un ícono para el grupo y podemos ver que en realidad nada ha cambiado. Solo para transmitir el punto, puedo agregarlo a los subelementos reales. ¿Verdad? Puedes ver el ícono. Pero por alguna razón, no podemos agregarlo al grupo y estamos un poco atascados. ¿Podemos resolver este problema? Por supuesto que sí. Podemos hacer ingeniería inversa y diseñar.

Podemos ampliar el menú. Podemos analizar una regla CSS que apunte a esta etiqueta individual y solucione nuestro problema. Pero es un poco engorroso. Todas esas soluciones se verán diferentes a la forma en que personalizamos el resto del menú. ¿Sobrevivirán a la próxima actualización de nuestras dependencias? Tal vez. Probablemente.

Entonces esto nos lleva a un dilema entre nuestra calidad de código y la calidad de nuestro diseño y nuestro presupuesto o nuestro plazo. Por cierto, esto no es una falta de respeto hacia Ant Design. Creo que son geniales. Y creo que son realmente personalizables. El problema comienza con los componentes. ¿Verdad? Así que voy a crear un componente llamado my-text, my-text, y veámoslo en VS Code para que pueda tener una fuente grande. Muy bien. Si no defino una propiedad llamada class name y no la extiendo en el elemento HTML correcto, entonces las clases no se pueden personalizar desde el exterior. Este es un problema o una característica de los componentes de React. Entonces cualquier autor de una biblioteca de componentes que venga con una vista predeterminada debe optar por todo lo que se pueda personalizar. La única forma de hacer que todo sea personalizable es no tener una vista predeterminada. Y eso es exactamente lo que son los componentes headless. Obtienes o bien ninguna marca o una marca muy básica que está diseñada para ser sobrescrita. Y no obtienes ningún estilo en absoluto.

Esta es una oferta bastante interesante. Aún necesitamos generar todo el HTML, todo el CSS, pero sabes qué? Esa es la parte fácil. Esto es definir tu vista en el lenguaje que conoces. Y lo que obtienes de forma gratuita o mediante el uso de una biblioteca es el comportamiento principal y todos esos comportamientos secundarios que te habrían llevado semanas escribir y depurar. Y vienen en dos variantes. Las API de los componentes headless vienen en dos variantes. Una de ellas es basada en componentes. Entonces obtienes un componente abstracto que toma tu vista o fragmentos de tu vista como hijos. O tienes la API basada en hooks que simplemente te proporciona un hook y necesitas construir un componente a su alrededor. Y te proporciona toda la funcionalidad que necesitas.

Esto es un poco abstracto. Veamos ejemplos. Entonces, Radix. Radix es una excelente biblioteca de componentes estilizados y estilos, lo que significa que tiene HTML predeterminado. Es muy básico y puedes reemplazarlo. Viene con muchos primitivos muy buenos. Se ve algo así.

Entonces, esto es a lo que me refería... Disculpa. Esto es a lo que me refería con la API basada en JSX. Tenemos este componente aquí y podemos ver que tenemos esos componentes que lo componen. Tenemos un popover.root, un trigger. Tenemos el portal que tiene el contenido. Pero todo lo que ves en la pantalla, toda la vista, se define explícitamente en el código. Mencioné que viene con un HTML predeterminado. Si quieres sobrescribirlo, esta es una pequeña característica ingeniosa. Agregas la propiedad como hijo y tomará tu fragmento de HTML, y lo usará tal como es. No lo envolverá con la vista predeterminada que viene. Y agregará diferentes props como ARIA y controladores de eventos, etc. Realmente es una biblioteca genial. Realmente me gusta su API. Su documentación es increíble.

Sin embargo, está limitado a primitivos. Entonces no encontrarás un selector de fechas o un calendario. Si necesitas eso, es posible que desees ver React ARIA. React ARIA es parte de la oferta de Adobe Spectrum. Es como un sistema de diseño completo. Pero esta es una de las bibliotecas internas que es de código abierto. Y también es un ejemplo de nuestro segundo tipo de API. Esta es una API basada en hooks.

Se ve algo así. Entonces, el comportamiento es que el usuario escribió su búsqueda. Y luego tienes este pequeño botón aquí que borra el campo de búsqueda. Genial. Veamos cómo se define este componente en el código. Muy bien. Tenemos este hook. Use search field. Toma varios parámetros y devuelve estas props que se deben extender en el HTML que elijas. Encuentro esta API realmente agradable. Muy elegante. Tiene una desventaja. Usa muchas refs. Muy liberal con las refs. Y se basa en una biblioteca de gestión de estado llamada React Stately. También es parte de Spectrum. Aparte de eso, diría que es una biblioteca muy interesante. Muchos componentes interesantes.

Hasta ahora, me he centrado en primitivas. Vamos al extremo opuesto del espectro de complejidad y veamos React Table. Hace un año, el autor de React Table dio una gran charla en este mismo escenario explicando por qué eligió el enfoque headless con React Table. Uno de los puntos que mencionó, por cierto, gran charla, recomiendo encarecidamente verla, y uno de los puntos que mencionó es la simplicidad de las APIs.

Entonces, React Table es un gran software. Hace muchas cosas. Es bastante avanzado. Puede reaccionar a los cambios en los datos, y tiene muchas funcionalidades. Muchas funcionalidades significan una API más compleja, ¿verdad? Hacemos más, necesitamos más para describirlo. Veamos cómo se ve la API. Voy a abrir esto en VS Code de nuevo. Tenemos algo llamado una tabla. Tiene getters y setters, y te da una lista que mapeas en tu vista. Y podrías pensar, como, esto es complicado, ¿verdad? Esto es mucho mapeo, esto es mucha información que necesito saber. Pero en realidad, todo lo que necesitas hacer es usar el hook para obtener la tabla. Todos saben cómo usar getters y setters, todos saben cómo usar un map, ¿verdad? Y todos saben qué hace este fragmento de código. Es solo un fragmento de HTML.

Entonces, después de un período inicial de adaptación, tus habilidades se pueden transferir desde lo que estás acostumbrado a este proyecto mucho más fácilmente que con una alternativa propietaria, ¿verdad? Piensa en cuánto puedes personalizar la vista de una tabla tan compleja. Si tuvieras que parametrizar todo, solo la cantidad de propiedades que necesitarías sería abrumadora en comparación con las partes interesantes de la funcionalidad. Entonces, en este punto, podrías pensar, ¿espera, entonces es solo más trabajo? Y yo diría que sí. Quiero decir, si estás construyendo un POC, sí, será más trabajo escribir algo de HTML y para un proyecto real con un diseño único, probablemente tendrás que personalizar todos los valores predeterminados, ¿verdad? No quieres que tu aplicación se parezca a cualquier otra aplicación que se haya desarrollado usando esta biblioteca de componentes. Así que tendrás que reescribirlo. Utilizarás una forma propietaria de describir los cambios. No será menos código, no será menos trabajo. Y sigo insistiendo en el lado propietario de las cosas. Pero cuando incorporas nuevos miembros al equipo, marca una gran diferencia si necesitan aprender todo desde cero o si pueden transferir sus habilidades. También argumentaría que es menos trabajo porque reduce las posibilidades de tener que reescribir. Si te encuentras con el límite de personalización más adelante en el proyecto, como suele ocurrir, estarás probablemente fuera de presupuesto y querrás terminarlo. Y cualquier solución a este problema será a expensas de tu tiempo de sueño. Y como persona que valora el sueño, considero que mitigar ese riesgo es muy valioso.

Entonces, nuestras experiencias con componentes headless en Codex, solo algunas lecciones aprendidas. Descubrimos que se pueden combinar fácilmente. No tienes que comprometerte. Puedes comenzar con lo que tenga sentido, y todavía tenemos ambas variantes, como componentes headless y, supongo, componentes headful que conviven y se llevan bien. También descubrimos que los componentes headless nos ayudan a mantener la separación de responsabilidades durante más tiempo, ¿verdad? Porque el comportamiento y la vista ya están separados, mezclar la lógica de negocio es como si ningún desarrollador quisiera lanzar la primera piedra. No quieres ensuciar algo que se ve limpio y, psicológicamente, crea un límite agradable.

Entonces, este es un tema doloroso. Escribimos nuestra propia biblioteca headless, ¿de acuerdo? Cuando maduró lo suficiente como para ser de código abierto, Radix ya estaba disponible, y dijimos, ah, esto no es lo que el mundo necesita en este momento. Pero nuestra deuda técnica es su ganancia, ¿verdad?, porque está ahí fuera. Estas son excelentes bibliotecas. Puedes usarlas. Deberías echarles un vistazo. Úsalas en tus proyectos.

Volviendo a la oportunidad. Correcto. Les mostré algunas primitivas excelentes y algunas piezas complejas de nicho. Pero lo que creo que falta en el espacio headless son los controladores diarios. Como formularios avanzados, galerías, ventas de automóviles, selección múltiple. Todo eso que necesitamos en casi todas las aplicaciones escasea en el espacio headless. Y creo que esta es una brecha en el mercado que puede impulsar la carrera de cualquiera. Y espero que uno de ustedes esté en este escenario el próximo año y nos cuente cómo llenar esta brecha llevó su carrera al siguiente nivel. Y con eso, muchas gracias. Estaré respondiendo preguntas allí mismo.

Excelente charla y tema realmente importante. He estado construyendo con Radix durante el último año y medio y ha mejorado mucho mi vida. Entonces, si no hubieras construido el tuyo propio, ¿con qué irías ahora? ¿Cuál sería tu elección personal? Yo elegiría Radix simplemente porque realmente me gustó su... La mayoría de la documentation está muy bien organizada y, en segundo lugar, me gusta la API y me gusta no tener que usar tantas referencias. Hay otras alternativas similares, pero Radix ha sido la más activa, han sido los más receptivos y tiene la mayor cantidad de componentes en la biblioteca. Sí, yo también respaldaría eso personalmente. Radix es genial.

Muy bien. Así que tenemos algunas preguntas aquí. ¿Qué pasa con las pruebas unitarias? ¿Es más fácil con componentes headless? No diría que es más fácil. Diría que facilita mantener la separación de responsabilidades, lo que hace que cualquier prueba sea más fácil. Entonces, si estás haciendo un buen trabajo manteniéndolo separado, es otra herramienta en tu cadena de herramientas.

¿Podrías usar componentes headless para distribuir el mismo sistema de diseño a equipos que trabajan con diferentes frameworks frontend? Es una gran pregunta. Diría que depende de qué biblioteca de componentes uses. Debido a que es headless, en realidad puedes tomar algo como Material Ui y ponerlo como un fragmento de alguna parte de un componente. Y en React Table, en realidad tienen ejemplos de uso de Material Ui y muchas otras bibliotecas frontend como parte de una tabla más grande.

Una cosa con la que luché un poco personalmente cuando estábamos usando radix es que, en ese momento, estábamos usando una solución de tipo CSS y JS. No siempre fue fácil estilizar los componentes headless de esta manera. ¿Existen soluciones de estilizado que sean más adecuadas para los patrones headless que otras? Diría que no a CSS y JS en general. Pero diría que todas estas bibliotecas se prestan a diferentes soluciones de estilizado mejor que la alternativa. Y no me encontré con ese problema específico. No sé cuándo lo tuviste tú. Pero creo que radix y muchas de estas bibliotecas hicieron un esfuerzo consciente para separarse de tu solución de estilizado. Eventualmente nos mudamos a Tailwind y resolvimos el problema de esa manera. Siempre tienes que seguir la tendencia. Tailwind es lo más nuevo. Tuvimos que reescribir toda nuestra aplicación. Tienes que pagar tus deudas a Tailwind. Exactamente. Aquí hay una pregunta realmente importante y una cosa que ha sido el mayor beneficio para mí al usar componentes de UI headless es la historia de la accesibilidad. Entonces, ¿radix tiene una buena accesibilidad como Spectrum Aria o hay fortalezas y debilidades diferentes? Por lo que he visto, es mucho mejor de lo que yo hubiera hecho manualmente, y es simplemente bueno. Para decirte que uno de nuestros desarrolladores solía dedicar al menos un día a la semana solo para usar lectores de pantalla y hacer todo su trabajo. Estaba contento con radix. Yo no llegué tan lejos. Genial. Sí, quiero decir, a todos nos importa la accesibilidad, pero a veces la realidad del desarrollo diario tiende a interponerse, especialmente en una pequeña startup, ya sabes, como, estás en movimiento apresurado.

Lo maravilloso de estas cosas es que si las usas, generalmente caes en el éxito y haces que las cosas sean accesibles por defecto. Esa es la verdadera ventaja aquí. Muy bien.

Tenemos varias preguntas donde básicamente esperamos opiniones sobre bibliotecas que hayas usado o no. Así que vamos a hacer esto.

¿Alguna opinión sobre MUI? He estado usando MUI. Lo que me gusta de MUI es que lo he utilizado en muchos espacios diferentes. He construido cosas para móviles con Dart y Flutter y estuvo presente allí. Con React y otras bibliotecas. Es muy rico y muy autoconsistente. Pero en términos de personalización, sería negligente si no dijera que están haciendo un esfuerzo. También tienen una parte headless en su oferta. En general, encontré que Material UI es menos personalizable que otras bibliotecas. Simplemente porque es tan autoconsistente. Cosas como el inkwell. Cuando ves una aplicación construida con Material UI, los desarrolladores tienen que hacer un gran esfuerzo para ocultar el hecho de que están usando MUI. Si trabajas lo suficiente con él, tu ojo lo detecta de inmediato. Sí, supongo que hay tipos de aplicaciones donde es mejor que la aplicación se parezca a los valores predeterminados de la plataforma porque es más accesible. Pero si eres una marca, una empresa comercial o una aplicación web pública, tal vez esa no sea la elección correcta. No todas las aplicaciones requieren un diseño único que sea exagerado y tenga que ser superespecial. Depende del contexto. Pero si eso es lo que le vendiste a tu cliente o PM o CEO, que tienes esta aplicación que se verá única y no como las demás, tarde o temprano tendrás problemas.

Genial. Algo que otras personas aparentemente quieren saber es tu opinión sobre Shadsey y UI. No estoy familiarizado, lo siento. He escuchado mucho ese nombre en Twitter, pero no he hecho clic en ninguno de los enlaces, así que no puedo ayudarte aquí tampoco. Pero si alguien sabe sobre eso, tal vez en la sesión de preguntas y respuestas del orador, puedan venir y educarnos. Sí, por favor. Exactamente, sí. Cuéntanos sobre tu biblioteca favorita. Realmente queremos escuchar sobre tu biblioteca favorita. Muy bien, veamos, ¿qué más tenemos aquí? Hay una pregunta sobre Kodaks. ¿Cómo funciona Kodaks con bibliotecas headless? ¿Hay algunas con las que funcione mejor o peor? Se lleva bastante bien. Es un editor visual, así que hasta que construyas, como con cosas como React ARIA, construyas una vista a su alrededor, es mejor usar VS code, pero una vez que tienes una vista real, funcionará bien y será divertido construir estos pequeños ejemplos. Genial, muchas gracias. Creo que eso es todo el tiempo que tenemos, pero si tienes más preguntas, puedes ir a la sesión de preguntas y respuestas después de esto y tener una conversación más profunda. Y si tienes algún comentario sobre Kodaks, avísanos, la mejor manera es a través de Discord, los enlaces están en la página de GitHub de los ejemplos. Gracias por escuchar. Absolutamente, ¡gracias!