Componentes React Polimórficos para el Cliente y el Servidor

Hola, mi nombre es Kirill y tengo una pequeña obsesión con los componentes de UI. De hecho, hago esto a tiempo completo en Progress, construyendo la próxima generación de la biblioteca CanDo React. Durante mi tiempo libre, me encanta explorar el espacio del sistema de diseño, y actualmente estoy construyendo un marco de sistema de diseño al que llamo BackerUI.

Pero basta de mí. Hablemos de React, y más específicamente, la nueva edición de React 19, los Componentes del Servidor, que si me preguntas, deberían haberse llamado simplemente Componentes de React. Pero de todos modos, cuando los Componentes del Servidor salieron inicialmente, prometieron un tamaño de paquete más pequeño, un mejor rendimiento y una mejora en la obtención de datos, lo que me llevó a creer que debería reescribir toda mi interfaz de usuario para usar los Componentes del Servidor. Resultó ser una idea realmente mala, incluso Lee Robinson tuvo que tuitear que los componentes del cliente están bien. En algún momento, incluso tuve un botón del servidor. Se veía exactamente como un botón regular, pero era en su mayoría inútil porque no tenía un evento de clic. Terminé manteniendo mis componentes del cliente.

Pero en el camino, me di cuenta de que tenía una variante del cliente y del servidor de algunos de mis componentes. En teoría, una tabla de datos podría beneficiarse enormemente al ser un componente del servidor, pero aún necesitaba proporcionar interactividad para implementar paneles de control más dinámicos o carritos de compras de comercio electrónico. Hoy quiero mostrarte cómo construí lo que llamo una tabla de datos polimórfica, un componente único que se puede utilizar en el cliente y como un componente del servidor. Pero antes de eso, asegurémonos de que todos estemos visualizando lo mismo cuando pensamos en una tabla de datos. Una tabla de datos generalmente muestra datos tabulares. Puede tener un encabezado, un cuerpo, múltiples filas con celdas en su interior que muestran datos formateados. Genial. Ahora estamos en la misma página. Pero aún terminé con dos componentes de UI muy similares.

Una tabla de datos del servidor, que solo enviaba HTML al cliente, tenía acceso a mi sistema de archivos e incluso a una instancia de base de datos. Y un componente del cliente, que era interactivo. Podía editar, ordenar y filtrar los datos sin tener que volver al servidor y tenía acceso a las API del navegador y al DOM. Por lo general, si estuviera construyendo mis publicaciones de blog personales, estaría perfectamente bien tener dos componentes de UI muy similares con diferentes propósitos. Sin embargo, si eres como yo y estás construyendo una biblioteca de UI reutilizable, ya sea de código abierto o algo para otros equipos en tu organización, hay algunas cosas que debes considerar. Primero está la duplicación de código. Probablemente no quieras mantener dos bases de código separadas que hacen casi lo mismo, renderizando un par de filas con celdas en su interior. Segundo, está cómo los consumidores de tu biblioteca modificarían aún más para cumplir con sus requisitos. Muchas aplicaciones tienen necesidades individuales que pueden requerir una combinación de código del servidor y del cliente, personalizando todas las partes de tu componente en el camino. Y por último, los requisitos cambian. Siempre lo hacen.

Alguien que comienza con el componente del servidor debería poder agregar fácilmente interactividad más adelante sin tener que reemplazar todo el componente. Ha surgido un patrón específico para ayudarnos a mezclar y combinar componentes del servidor y del cliente. Probablemente hayas visto este diagrama al hablar del patrón de composición.

Todo parece bien en teoría, pero a menudo se aplica a nivel de aplicación. Cuando nos enfocamos en el nivel del componente, las bibliotecas de UI suelen estar en modo cliente completo, lo que disminuye los beneficios de usar componentes del servidor. Veamos por un momento cómo se vería el árbol de renderizado de una data tabla y veamos si podemos aplicar el patrón de composición allí. Si has intentado implementar una tabla de data antes, rápidamente te darás cuenta de que necesitas código del cliente en casi cualquier parte del árbol. Ya sea para accessibility o para agregar una función simple de selección de filas, la mayor parte del árbol de renderizado no podrá utilizar componentes del servidor en absoluto.

Esto es problemático porque los consumidores de tu tabla de data aún pueden querer mantener parte del renderizado en el servidor. Pero según las reglas de los componentes del servidor, sabemos que si bien los componentes del servidor pueden renderizar componentes del cliente, lo contrario no es cierto. Sin embargo, hay una forma de lograr esto pasando todo a través de la propiedad de children pod, pero lo exploraremos en un minuto. Ahora, volvamos a nuestra tabla de data.

Mi ejemplo favorito es una tabla de API que muestra documentación para un componente de UI o software de cualquier tipo. Para que todo sea legible y hermoso, a veces estamos renderizando markdown con bloques de código en su interior, pero las bibliotecas de markdown son pesadas y a menudo terminan en tu paquete del cliente. Es aún peor si quieres resaltar la sintaxis para los bloques de código.

Lo que quiero poder hacer es renderizar una celda de markdown sin afectar el código del cliente. Sé que hay otras formas de lograr esto, pero la implementación más sencilla para mí sería algo como esto, pasando una celda especializada que haga todo el trabajo sin afectar negativamente el paquete del cliente.

Ahora, profundicemos en cómo podemos lograr esto utilizando un patrón que he llamado componente polimórfico, un componente que puede renderizar cualquiera de sus nodos tanto en el cliente como en el servidor. Para lograr esto, simplemente debemos seguir algunas reglas básicas. Primero, los componentes no deben renderizar sus propios hijos. Y segundo, su lógica del cliente debe estar separada.

Con esas dos reglas simples, podremos renderizar componentes personalizados en todo el árbol de componentes sin romper la funcionalidad del cliente y aún así poder convertirnos en un componente completamente del cliente para aplicaciones que no admiten o no requieren componentes del servidor. Si aplicamos esas reglas correctamente, el árbol de renderizado debería verse algo así. Cada nodo en el árbol es agnóstico, lo que significa que se puede renderizar tanto como un componente del cliente como del servidor. Además, las partes del cliente de un componente se extraen en una estructura de cliente donde no afectan el renderizado del componente original.

Ahora repasemos la primera regla de no ser responsable de tus propios hijos en el contexto de los componentes de UI, por supuesto. Si anteriormente nuestro componente raíz de la tabla de datos estaba renderizando directamente el rol, ahora estamos introduciendo un componente intermedio. Aún no he encontrado un buen nombre para ellos, pero por ahora los llamo componentes de vista. La idea de un componente de vista es ensamblar la ranura real que se puede personalizar, en nuestro caso el rol, y preparar a sus hijos para que si el rol necesita ser un componente del cliente o del servidor, sus hijos, las celdas, no se vean afectados por esta decisión, lo que les permite ser cualquier cosa según los requisitos de la aplicación.

Volviendo a nuestro caso de uso con la celda de markdown, el patrón de renderizado nos permitiría renderizar un componente del servidor en una hoja sin importar cualquier otra personalización que hayamos realizado en el árbol. Ahora pasemos a nuestra segunda regla. Eventualmente, tú o tu gerente de producto querrán agregar una función simple de selección de roles y no les importará mucho la implicación de rendimiento si llevamos todo el componente al cliente.

Cuando estaba jugando por primera vez con los componentes del servidor, pensé que simplemente podía agregar cualquier cosa de React a un componente y funcionaría en el servidor en lugar del cliente. Pero si intentas agregar estado a un componente, que podría renderizarse en el servidor, como nuestras partes agnósticas de la tabla de datos, rápidamente te encontrarás con un error. Lo mismo ocurre al adjuntar eventos DOM, porque ¿cómo más sabrías cómo cambiar el estado? Entonces, lo que estamos viendo en la pantalla ahora no funciona.

Para que funcione, debemos extraer toda la lógica del cliente en un componente separado. Una vez más, el mejor nombre que se me ocurrió es agregar 'cliente' al final del nombre del componente. Esto nos permite evitar el renderizado del componente sin afectar directamente el árbol y solo proporcionar el contexto del cliente. Esto nos permite consumir este contexto desde la parte del cliente de nuestros otros componentes. Nuevamente, solo agregando lógica específica del cliente.

En nuestro caso de uso, eso sería la parte del cliente del rol, que solo debe agregar un evento de clic y agregar un nombre de clase si el estado del cliente indica que el rol está seleccionado. Ampliando la vista para ver la imagen completa, nuestros componentes móviles se ven así, renderizando de izquierda a derecha y su lógica del cliente se extrae en un componente separado con la directiva 'cliente'.

Ahora, intentemos adivinar qué sucede si usamos este componente en una aplicación cliente regular, por ejemplo, una aplicación Create React o una aplicación Vite. El componente no funciona correctamente, ya que sus partes agnósticas se convierten en componentes del cliente. Nuestros componentes aún no funcionarán, pero eso depende de los frameworks subyacentes, no de nuestro componente.

Sin embargo, si consumimos nuestro componente en un entorno de componente de servidor React a la derecha, como Next.js o una aplicación Wacom, podríamos esperar que nuestro componente agnóstico se convierta en componentes del servidor, dejando su JavaScript en el servidor y solo enviando o transmitiendo, si prefieres, el HTML que han producido. Las partes del cliente de nuestro componente se envían en un paquete separado ya que las hemos separado del componente en sí.

Con esto, concluimos nuestro proceso de construcción de un único componente polimórfico que puede ser utilizado como componente del cliente o como componente del servidor o cualquier cosa intermedia, en realidad, con un tamaño de paquete mínimo, interactividad y acceso a las API tanto del servidor como del cliente desde sus partes correspondientes. Gracias por ver. Si te ha gustado esta charla, puedes seguirme en Twitter o X, si lo prefieres. Si quieres ver mi trabajo, actualmente estoy construyendo componentes polimórficos para Gendo React y también puedes echar un vistazo a mi marco de diseño de sistema de código abierto, Baka.UI. ¡Adiós!