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

Rate this content
Bookmark

¿No estás cansado de repetirte? ¿Cansado de repetir el mismo código una y otra vez en tus proyectos de React? En esta charla, descubriremos el poder de los componentes sin cabeza, un patrón de diseño que separa la lógica de la capa de presentación, permitiéndote crear componentes de IU reutilizables y flexibles.
Exploraremos cómo los componentes sin cabeza pueden simplificar tu proceso de desarrollo, ahorrándote tiempo y esfuerzo. Examinaremos bibliotecas populares de componentes sin cabeza y proporcionaremos consejos para integrarlas en tus proyectos. Ya seas un principiante o un desarrollador experimentado, únete a nosotros para descubrir cómo los componentes sin cabeza pueden ayudarte a agilizar tu desarrollo de React y crear interfaces de usuario personalizables y de alta calidad.

25 min
02 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Los componentes sin cabeza son eficientes para el desarrollo de aplicaciones, pero hay mucho trabajo involucrado, especialmente para los menús. La barrera de personalización es un problema con las bibliotecas de componentes, pero se puede resolver a través de la ingeniería inversa y el diseño. Los componentes sin cabeza no ofrecen ninguna marca o marca básica que se pueda sobrescribir, lo que proporciona flexibilidad en el código y calidad de diseño. Radix y React ARIA son bibliotecas de componentes recomendadas con diferentes APIs. La experiencia de Kodaks con los componentes sin cabeza destaca la capacidad de mezclar y combinar fácilmente y el potencial de vacíos en el mercado en el espacio sin cabeza. Radix es una opción popular para los componentes sin cabeza debido a su API bien documentada y fácil de usar. Los componentes sin cabeza ayudan en las pruebas, la distribución de sistemas de diseño y la accesibilidad. MUI es una biblioteca autoconsistente y rica, mientras que Radix se centra en la accesibilidad y la accesibilidad por defecto. Kodaks se integra bien con las bibliotecas sin cabeza y agradece los comentarios a través de Discord.

Available in English

1. Introducción a los Componentes Headless

Short description:

Soy Omri, el CTO de Kodaks, una empresa de Wix. Hoy hablaré sobre los Componentes Headless, su importancia, cómo utilizarlos de manera efectiva y las opciones populares. También compartiré nuestra experiencia en Kodaks. Los componentes son eficientes para el desarrollo de aplicaciones, pero hay mucho trabajo involucrado, especialmente para los menús. Muchos de nosotros utilizamos bibliotecas de componentes como Material UI y Ant Design para simplificar el proceso.

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.

2. The Customizability Wall and Solving Problems

Short description:

Los desarrolladores hablan y podrás desarrollar una interfaz de usuario atractiva muy rápidamente. Pero hay un problema con todos ellos, ¿verdad? Lo llamo el muro de personalización. 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. Así que, solo por mostrar de manos, estamos aquí estrellados contra este muro de personalización. 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. 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.

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.

3. The Benefits of Headless Components

Short description:

Podemos ampliar el menú, pero es un poco engorroso. El dilema entre la calidad del código, la calidad del diseño, el presupuesto y el plazo. El problema comienza con los componentes. Los componentes headless no ofrecen ninguna marca o una marca básica que se pueda sobrescribir. Proporcionan los comportamientos principales y secundarios en API basadas en componentes y hooks.

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.

4. Ejemplos de Bibliotecas de Componentes Estilizados y APIs

Short description:

Radix es una excelente biblioteca de componentes estilizados con HTML predeterminado y muchos primitivos. Ofrece una API basada en JSX donde todo se define explícitamente en el código. Puedes sobrescribir el HTML predeterminado usando una propiedad secundaria. Si necesitas más que primitivos, echa un vistazo a React ARIA, una API basada en hooks y parte de la oferta de Adobe Spectrum.

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.

5. Explorando el Hook 'Use search field'

Short description:

El hook 'Use search field' es una API agradable y elegante que devuelve props para ser extendidos en el HTML elegido. Sin embargo, depende en gran medida de las refs y utiliza React Stately para la gestión del estado.

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.

6. Explorando React Table y Personalización

Short description:

React Table es un gran software con muchas funcionalidades, lo que significa una API más compleja. Sin embargo, el uso del hook para obtener la tabla simplifica el proceso. Aunque puede requerir un aprendizaje inicial, transferir habilidades a este proyecto es más fácil que con una alternativa propietaria. Personalizar la vista de una tabla compleja sin parametrizar todo puede ahorrar tiempo y esfuerzo. Aunque pueda parecer más trabajo, reduce las posibilidades de tener que reescribir y mitiga el riesgo de exceder el presupuesto y sacrificar el sueño.

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.

7. Experiencias con Componentes Headless

Short description:

Nuestras experiencias con componentes headless en Codex nos enseñaron que se pueden combinar fácilmente. Los componentes headless ayudan a mantener la separación de responsabilidades y crean un límite agradable. Escribimos nuestra propia biblioteca headless, pero también hay excelentes bibliotecas como Radix disponibles. El espacio headless carece de controladores diarios como formularios avanzados y galerías, lo que crea una brecha en el mercado que puede impulsar carreras.

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.

8. Elección de Radix para Componentes Headless

Short description:

He estado construyendo con Radix durante el último año y medio y ha mejorado mucho mi vida. Elegiría Radix debido a su documentación bien elaborada, su API fácil de usar y su desarrollo activo. Radix es mi elección personal.

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.

QnA

Pruebas unitarias y estilizado con Componentes Headless

Short description:

Los componentes headless facilitan mantener la separación de responsabilidades, lo que ayuda en las pruebas. Se pueden utilizar para distribuir el mismo sistema de diseño a equipos que trabajan con diferentes frameworks frontend. Estilizar componentes headless puede ser un desafío, pero diferentes bibliotecas ofrecen mejores soluciones. Radix tiene buena accesibilidad y ayuda a los desarrolladores a hacer las cosas accesibles por defecto.

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.

Opiniones sobre bibliotecas y la integración de Kodaks

Short description:

El uso de bibliotecas como MUI puede llevar a diseños accesibles por defecto. MUI es autoconsistente y rico, pero menos personalizable en comparación con otras bibliotecas. Las aplicaciones pueden elegir los valores predeterminados de la plataforma para la accesibilidad o diseños únicos para la marca. El orador no está familiarizado con Shadsey y UI, pero anima a otros a compartir su conocimiento. Kodaks funciona bien con bibliotecas headless, especialmente al construir una vista con React ARIA. Se puede proporcionar feedback sobre Kodaks a través de Discord.

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!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Advanced Conference 2021React Advanced Conference 2021
6 min
Full-stack & typesafe React (+Native) apps with tRPC.io
Top Content
Why are we devs so obsessed with decoupling things that are coupled nature? tRPC is a library that replaces the need for GraphQL or REST for internal APIs. When using it, you simply write backend functions whose input and output shapes are instantly inferred in your frontend without any code generation; making writing API schemas a thing of the past. It's lightweight, not tied to React, HTTP-cacheable, and can be incrementally adopted. In this talk, I'll give a glimpse of the DX you can get from tRPC and how (and why) to get started.
React Summit 2023React Summit 2023
22 min
Thinking in React Query
In this talk, I'll explain React Query from a different perspective. After having maintained React Query for over two years and having answered many questions (often the same ones multiple times), I feel like there might be a fundamental understanding missing about the lib. I'll start with a quick introduction about my journey into open source and how I got to know React Query, followed by showing which mindset change is beneficial when working with React Query - how to "think in React Query". I'll have 3 major takeaways: 1) React Query is not a data fetching library It's an async state manager, we'll quickly talk about what makes a state manager, why React Query is one and what "async state" means. 2) staleTime is your best friend I've seen a bit of confusion about how to use React Query as a state manager, so I'll explain why setting staleTime is mostly all you need 3) parameters are dependencies This is important to understand to show the boundaries between client state and server state, and is essential when doing state management with React Query I will then end with a note on "separation of concerns" and about the tradeoffs of just calling `useQuery` wherever you need it in your component tree.
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.

Workshops on related topic

React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
React Summit 2023React Summit 2023
31 min
From Idea to Production: React Development with a Visual Twist
WorkshopFree
Join us for a 3-hour workshop that dives into the world of creative React development using Codux. Participants will explore how a visually-driven approach can unlock creativity, streamline workflows, and enhance their development velocity. Dive into the features that make Codux a game-changer for React developers. The session will include hands-on exercises that demonstrate the power of real-time rendering, visual code manipulation, and component isolation all in your source code.
Table of the contents: - Download & Setup: Getting Codux Ready for the Workshop- Project Picker: Cloning and Installing a Demo Project- Introduction to Codux Core Concepts and Its UI- Exercise 1: Finding our Feet- Break- Exercise 2: Making Changes While Staying Effective- Exercise 3: Reusability and Edge Case Validation- Summary, Wrap-Up, and Q&A
React Advanced Conference 2022React Advanced Conference 2022
206 min
Best Practices and Patterns for Managing API Requests and States
Workshop
With the rise of frameworks, such as React, Vue or Angular, the way websites are built changed over the years. Modern applications can be very dynamic and perform multiple API requests to populate a website with fresh content or submit new data to a server. However, this paradigm shift introduced new problems developers need to deal with. When an API request is pending, succeeds, or fails, a user should be presented with meaningful feedback. Other problems can comprise API data caching or syncing the client state with the server. All of these problems require solutions that need to be coded, but these can quickly get out of hand and result in a codebase that is hard to extend and maintain. In this workshop, we will cover how to handle API requests, API states and request cancellation by implementing an API Layer and combining it with React-Query.
Prerequisites: To make the most out of this workshop, you should be familiar with React and Hooks, such as useState, useEffect, etc. If you would like to code along, make sure you have Git, a code editor, Node, and npm installed on your machine.
Node Congress 2022Node Congress 2022
134 min
Deploying a decoupled restaurant review site to production with Strapi and Platform.sh
WorkshopFree
Node.js has become an increasingly popular language to build and deploy backend APIs. In a world of legacy CMSs adopting decoupled implementations, plenty of frameworks have sprung up to classify themselves as "headless" CMSs, designed from the start to provide an easy way to personalize content models, administer permissions and authentication, and serve a content API quickly.
Strapi, one of the leaders in this space, has recently released their v4 version of the framework, and with Platform.sh it can be deployed alongside a number of frontends within the same project, giving a drastically simplified development experience working with decoupled sites. In this workshop, we'll deploy a Strapi demo application, which has been configured to serve a restaurant review site.
Piece piece you will add database services, tests, and frontends, all within the safety of isolated development environments. At the end, each user will have a functioning decoupled site, and some greater understanding of working with decoupled sites in production.