SolidJS: Reactividad Desencadenada

Hola, soy Ryan Carneato, autor de Solid.js, y hoy voy a presentar una introducción a ello. ¿Qué es Solid? Es una biblioteca declarativa de JavaScript para construir interfaces de usuario como tantas otras que han venido antes.

Solid en la superficie al menos es un framework muy parecido a React. Valora las mismas cosas. Flujo unidireccional, segregación de lectura y escritura, e interfaces inmutables. Está construido sobre los mismos bloques de construcción. Primitivas similares a hooks, componentes de función y JSX. Y tiene muchas características similares. cosas como portales y fragmentos, transiciones de suspensión, SSR en streaming, y algunas otras también. Que no están en React, como directivas personalizadas y obtención de datos.

Pero hay un pero. Uno bastante grande. Solid no se parece en nada a React. Solid está construido completamente sobre reactividad de grano fino, similar a MobX y Vue. Sus componentes solo se renderizan una vez. Y no hay un DOM virtual. Todo el modelo mental es completamente diferente. Mismos valores, implementación completamente diferente. Pero, ¿qué significa eso realmente? Bueno, el desarrollo web front-end moderno durante años ha sido sobre componentes. Componentes de clase, componentes de función, componentes de opción, componentes web. Y por una buena razón. Los componentes son bloques de construcción esenciales que permiten que nuestros programas sean modulares y componibles. Sin embargo, en casi todos los frameworks de JavaScript, tienen implicaciones en tiempo de ejecución. El modelo de actualización y los ciclos de vida están ligados a ellos. Y esto ha llevado básicamente a dos visiones del mundo. O usas un diff de arriba hacia abajo como un DOM virtual o un literal de plantilla de etiqueta. O alternativamente, confías mucho en la compilación para separar la creación de la actualización. Pero ambos todavía tienen componentes que básicamente se ejecutan de arriba hacia abajo. Y esto plantea la pregunta, ¿cuándo y qué memorizar? Esto es importante para el rendimiento, porque si vas a llamar a algo una y otra vez, no quieres repetir el trabajo. Hay una gran charla de Sean en React Comp 2021 que aborda exactamente esto.

Tu primera intuición podría ser construir tu aplicación de tareas en un framework como React. Algo así. Declara algún estado y conéctalo. Pero con cualquier cambio, incluso no relacionado con la lista de tareas, estarías volviendo a renderizar toda la lista. Pero tal vez eso esté bien. Por eso existe un Virtual DOM, para asegurarse de que esto no sea tan costoso. Pero tal vez aún quieras optimizar. A medida que tu programa crece, aplicas tus optimizaciones, y las cosas pueden empezar a verse así. Tal vez añadas un filtro y algo de tematización.

Y no hay nada intrínsecamente malo en esto. Pero ahora estamos anotando cosas con memo, y use memo, y use callback. Y añadiendo nuestros arrays de dependencias, y asegurándonos de que todo funcione exactamente como queremos. Pero es un poco diferente de donde empezamos.

Así que... Compilémoslo. Y esto podría ser con lo que termines. Para ser justos, este no es el código que escribirías, esta es la salida compilada, una especie de pseudo-código, de un compilador experimental en el que el equipo de React está trabajando. Pero en realidad no es tan diferente de lo que haría un framework como Svelte. Es un montón de comprobaciones de igualdad referencial superficial, que en cada punto de decisión, se vuelven a ejecutar cuando tu componente está marcado como necesitando una actualización. El terreno común es un estado de actualización del componente, luego ejecuta una función de actualización, y verifica contra estos valores memorizados, como se muestra aquí en este memcache.

Pero, ¿y si no lo hiciéramos? ¿Y si solo ejecutáramos lo que necesitaba ser ejecutado, y no dependiéramos en gran medida de la compilación? ¿Y si los límites de nuestros componentes no dictaran el rendimiento de nuestras aplicaciones web? Para hacer eso, necesitamos volver al principio. Y voy a ir todo el camino de regreso al principio. Recuerda, el primer programa que escribiste. Fue un Hello, World. Pudiste establecer algunos datos en una variable y registrarlos en la consola. Y no pasó mucho tiempo antes de que te dieras cuenta, bueno, podrías establecer un nuevo valor a esa variable y registrarlo de nuevo. Sabes, este es el comienzo de la programación.

Entonces te diste cuenta, bueno, eso es mucha repetición, así que vamos a extraer eso en una función. Tal vez una función greet aquí, y podemos tener un seter name y luego llamar a greet, y luego seter name y llamar a greet de nuevo. Y todo esto es genial, pero en cierto punto, tal vez pienses, cada vez que establezco el nombre, quiero que salude sin tener que llamarlo. Y ahí es donde entra la reactividad.

La reactividad se basa en primitivas. Es un poco como una promise en JavaScript. En nuestro caso, vamos a introducir la primera primitiva aquí, y se llama una signal. Las signals son relativamente simples. Son solo un contenedor sobre un valor. Tienen una función get name aquí y un seter, set name. Y en este caso, tenemos que reemplazar esta asignación que tenemos aquí ahora con set name para que podamos actualizarlo. Y necesitamos reemplazar nuestro name. Necesitamos llamarlo ahora, porque es una función. Y una vez que hemos hecho eso, básicamente actúa igual. Todavía podemos ver Hello World y Hello Solid JS.

Eso en sí mismo, para ser justos, no es terriblemente interesante. Así que tenemos otra primitiva que vamos a elegir aquí llamada create effect. Y lo que hacen los effects es que nos permiten interactuar con nuestro mundo cada vez que una signal cambia. En este caso, vamos a tomar nuestro console log y lo vamos a poner en el effect y hacer que escuche a name. Esto nos permite limpiar el resto de este código, esencialmente. Así que ahora solo creamos nuestra signal para el name y luego creamos el effect que se ejecuta una vez. Y luego, cuando establecemos el name de nuevo, se ejecuta de nuevo. Y de nuevo, hace esto porque llamamos a names una función que nos permite interceptar la lectura de ese valor. Y esto puede extenderse fuera del effect en sí porque esto no es un truco de compilador. Esto es completamente en tiempo de ejecución. Así que podemos hacer un like uppercase y ahora básicamente podemos llamar a nuestro name aquí y cambiarlo a mayúsculas, ponerlo en nuestro effect. Y porque solo está usando la pila de tiempo de ejecución, ahora podemos ver hello world y hello solid js en mayúsculas. Así que podrías preguntarte cómo funciona esto. Y todo se reduce a esta idea de reactividad de grano fino. Crear una biblioteca reactiva de grano fino se puede hacer en unas 50 líneas de código.

Voy a simplificarlo aún más aquí con fines de demostración, pero todo comienza con signals como vimos. Y en su núcleo, simplemente ves una signal como un par de funciones getter y setter que cierran sobre un valor. Por supuesto, hay un poco más que eso. Y para eso, vamos a necesitar suscripción.

Así que actualicemos nuestras signals, hagamos un poco más. Ahora al leer lo que queremos hacer es verificar si hay un observador actual. Y si lo hay, vamos a agregarlo a un nuevo conjunto de suscriptores que creamos cuando creamos nuestra signal. A la derecha, todavía actualizamos nuestro valor, pero ahora en realidad iteramos sobre esos suscriptores y los llamamos para básicamente notificarlos de que algo ha cambiado. Y eso que necesita ser notificado son nuestros effects, que son el otro lado de nuestra ecuación.

Aquí puedes ver la implementación para get current observer. Lo que tenemos es una pila. Este contexto es solo un array, contexto global. Y simplemente tomamos lo que está en la parte superior del array para ver qué se está ejecutando actualmente. Para nuestro effect en sí, cuando se crea, se ejecuta inmediatamente. Y luego pasa por el ciclo de limpiar dependencias o suscripciones, empujarse a sí mismo en esa pila, para que cuando ejecutemos la función proporcionada, esté allí y pueda ser agregado a las suscripciones. Y finalmente, se sale de la pila. Voy a poner el código lado a lado, para que puedas ver esto mejor mientras revisamos nuestro ejemplo. Esencialmente, creamos nuestra signal, como nuestra signal de name, y devuelve nuestras funciones de lectura y escritura. Luego creamos nuestro effect. Se ejecuta, empujándose a sí mismo en esa pila. Luego ejecuta la función y lee de nuestra signal de name, en cuyo punto ve el observador actual, que es ese effect, y lo agrega a sus suscriptores. Luego lo registra en la consola y el effect termina de ejecutarse, saliéndose de la pila. Algún tiempo después, nuestra signal se actualiza, lo que establece el nuevo valor y luego ejecuta nuestra lista de suscriptores. En este caso, es ese effect, que lo ejecuta de nuevo, limpiando las dependencias y simplemente comenzamos todo el ciclo de nuevo. Y eso es realmente todo. A partir de ahí, podemos construir una base para otras primitivas. Muchas de ellas no son esenciales. Pueden ser utilizadas según sea necesario, pero un ejemplo de algunas importantes que se envían con Solid son createMemo, que puede ser utilizado para almacenar en caché cálculos costosos, createStore, que es un proxy que permite reactividad profundamente anidada, y createResource, que es nuestra primitiva de primera mano para la obtención de datos y suspense. Pero suficiente sobre reactividad por ahora. Volvamos a nuestro ejemplo.

Cuando enseñamos reactividad, siempre usamos console logs, pero hagamos algo un poco más sustancial aquí. Vamos a crear un elemento dom esta vez y ver qué hace. Así que lo que vamos a hacer aquí es vamos a crear un header y vamos a establecer algo de texto en él y luego lo vamos a adjuntar al dom.

Bien y luego vamos a tomar establecer ese texto en él y ponerlo en el effect. Así que ahora, cada vez que el nombre cambie, actualizará el dom. En este caso, establecemos el solidjs de inmediato. Así que ni siquiera lo ves. Solo vemos hello solidjs porque se actualizó de inmediato. Así que lidia con eso.

Vamos a crear un botón y pondremos el setter dentro de un controlador de clic. Así que solo estamos usando APIs de dom vanilla aquí para que podamos hacerlo funcionar. Y ahí vamos. Ahora nuestro Hello World tiene un botón de saludo y cuando hacemos clic en saludar, lo cambia a hello solidjs. Pero quiero decir, esto es mucho código. ¿Quién quiere escribir todo ese vanilla js? ¿No sería genial si pudiéramos simplemente escribir algo como jsx? Y en Solid, puedes porque jsx en Solid son solo elementos DOM. Así que este es un verdadero elemento de botón HTML que estamos creando aquí y solo vamos a poner un controlador de clic en él, limpiar ese código, y nuestro ejemplo aún funciona. Y podemos darle al header el mismo tratamiento. La única diferencia aquí, sin embargo, es que el header tiene una declaración reactiva y el compilador de Sol puede ver realmente que estamos llamando a una función en la expresión por lo que sabe envolverlo automáticamente en effect. Y cuando hacemos eso, efectivamente, todavía funciona. Y es un poco más limpio aquí pero realmente no escribimos nuestras aplicaciones de esta manera. Así que vamos a abstraer esto en una función o un componente por así decirlo. Pero esto es solo una función. Podemos limpiar esto un poco y tal vez devolver los elementos como un array. Y luego podemos simplemente llamar a nuestra función y simplemente adjuntarla. Y como puedes ver, claramente todavía funciona. Pero vamos a incluir el JSX un poco más, limpiar un poco más, eliminar todo eso, y luego formatearlo con prettier. Y aquí vamos. Bien. Podemos realmente reemplazar el array con un fragmento porque eso es todo lo que son los fragmentos en Solid. Y esto está empezando a verse bastante bien.

Lo último con lo que realmente tenemos que lidiar ahora es simplemente cómo nos estamos adjuntando a los DOMs. Así que Solid proporciona una función de renderizado y podemos simplemente renderizar nuestro componente greet y ahí estamos. Esto se parece a cualquier framework moderno.

Pero hay una gran diferencia aquí. Los componentes de Solid solo se ejecutan una vez porque como viste, solo estábamos llamando a esta función. Así que si pongo un console log aquí, como greet, digamos greet. Y verás un log cuando lo presione, no está registrando de nuevo. Solo registra una vez. Bien. Así que hagamos eso una vez más. Bien. Aquí estamos. Hola mundo. Mira greet, presiónalo. Solo una vez. Y sí.

Extendamos esto un poco más. Vamos a usar dos componentes greet ahora. Vamos a poner esto dentro de un componente app que usamos. Y al hacer esto, puedes ver que cada componente puede envolver su propio estado. Así que ahora tenemos dos de ellos, podemos ver que registra el console greet dos veces ahora, pero cuando actualizamos cada uno, no registra de nuevo y se actualizan independientemente, cada uno manteniendo su propio estado porque tienen su propia señal. Pero en realidad podemos tomar esta señal y extraerla directamente del componente superior. Y ahora está compartida porque ambas instancias del componente están leyendo de la misma variable, como funciona en JavaScript. Y efectivamente, no importa qué botón presiones, actualizan el mismo estado y los console logs solo registran en la creación en una actualización. Pero la mayoría de las veces vas a poner esto en props. Así que pongamos esto en app y pasémoslo como props. Así que también podemos mover el controlador de clic hacia arriba y pasarlo también. Y así es como funciona la composición en Solid. Lo importante que hay que entender aquí, sin embargo, es solo donde está ese texto del encabezado, eso es lo que realmente se actualiza. Estamos compartiendo el estado pasado aquí, pero los componentes solo se ejecutan una vez.

Así que este app console log mostrará que incluso cuando lo actualizamos, no lo va a registrar de nuevo. Y de hecho, para hacer eso más claro, voy a tomar este set name y voy a hacer que incremente de manera diferente para cada componente, aunque esté usando el estado compartido. Aunque estamos pasando todo, cuando realmente hacemos una acción, solo hay dos efectos en toda esta página y esos son para que ambos encabezados actualicen ese texto.

Bien. Entonces, ¿qué está pasando aquí? Bueno, es por la forma en que manejamos los component props. En Solid, lo único que realmente transformamos es el JSX. Y para los componentes, cuando vemos una expresión que contiene JSX o algo que podría ser reactivo, como una llamada a función, lo envolvemos en un getter, como este get name. Y lo que esto hace es permitir que se evalúe de manera perezosa. Es muy similar a lo que hacemos con los elementos DOM, donde si vemos algo que podría ser reactivo, lo envolvemos en un efecto. Básicamente, todo se evalúa de manera perezosa hasta el efecto final, que realmente hace el trabajo. Y como dije, solo hay dos efectos en esa demo. El único trabajo que se está haciendo es actualizar ese único nodo de texto dentro de cada encabezado. Nada más se re-ejecuta.

Lo último que probablemente necesites saber sobre el rendering en Solid es que estamos tratando con nodos DOM reales. Y la creación puede ser costosa. Así que necesitamos hacer un manejo especial para cosas como listas. Un simple array.map nunca correría sobre cada elemento y mapearía nuevos resultados. Y no queremos crear todos los nuevos nodos DOM cada vez que añadimos algo a una lista o la ordenamos. Así que necesitamos hacer algo un poco especial aquí. Para Solid, tenemos funciones auxiliares. Pero elegimos enviarlas en forma de componentes ya que encajan bien con nuestros patrones y son muy composables como el resto de las primitivas en nuestro sistema. ¿Qué quiero decir con composable? Bueno, imagina ahora que necesitamos actualizar esto. Solo queremos mostrar 10 elementos en cada página. Necesitamos paginar. Afortunadamente, alguien ha creado este componente para eso. Entonces, ¿qué hacemos? Bueno, tal vez lo importamos y ahora solo cambiamos nuestro for component. Y como puedes ver, es exactamente el mismo patrón. Las listas se convierten en listas paginadas o virtualizadas. Los condicionales se convierten en layouts o suspense o límites de error. Es todo lo mismo.

Sabes, si no te gusta el componente for de Solid, es solo un componente. Es runtime, puedes escribir el tuyo propio. Esto es realmente poderoso. Y armado con esto, podemos regresar hasta el principio con nuestro ejemplo de tareas.

Así que he recreado ese ejemplo en Solid que vimos al principio, y tenemos una lista de tareas y tenemos un manejador que puede, hemos configurado nuestro estado de nuestras tareas y tenemos un manejador que actualizará nuestras tareas a hechas. Y lo que hemos hecho aquí es que estamos pasando un filtro de visibilidad y un selector de color. Y esto se pasa completamente a través de nuestro añadir tareas para establecer la temática. Así que esto añade un poco más de complejidad o eso pensarías, pero en el caso de Solid, sin la necesidad de añadir ningún memo o use callback o básicamente, o arrays de dependencias o básicamente cualquier cosa adicional, podemos simplemente tomar nuestra lista, filtrarla basado en ese prop y solo tener las cosas que necesitan actualizarse, actualizarse. Por ejemplo, cuando hacemos clic en este tres, ahora vamos a actualizarlo a tarea o cuando lo desmarcamos, lo actualizamos. Cuando cambiamos el filtro, se llama. Pero como puedes ver, actualizar la tarea no hizo que se llamara al filtro. Y si volvemos, bueno, vamos a tener que recrear esos tres elementos. Así que sí, llamamos al filtro de nuevo y actualizamos tres veces, pero este prop que se pasa aquí para el color del tema, nosotros cambiando esto, no causa que las actualizaciones de tareas o el filtro se actualicen. Simplemente funciona. Y todo esto lo hicimos sin ningún tipo de memo. De hecho, la parte más difícil de hacer este ejemplo fue tratar de mostrar qué se actualizó porque tan poco lo hace. Esto es lo que sucede cuando tienes rendering y actualizaciones detalladas.

Para mí, llamo a esto la ventaja reactiva. Básicamente, los componentes se ejecutan una vez. No hay reglas de hooks o cierres obsoletos o arrays de dependencias para el caso. Las plantillas se compilan en notas DOM reales. Esto es una abstracción súper baja sobre el DOM. Significa que tienes esa salida de emergencia. Necesitas hacer algo con el DOM, está justo ahí. Pero lo más importante es que el estado es independiente de los componentes. Los límites de los componentes son para tu beneficio cómo quieres organizar tu código. No se trata de rendimiento. El rendimiento es bueno independientemente. Así que si quieres experimentar la libertad tú mismo, tal vez prueba SOLID.