SolidJS: Reactivity Unchained

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

Solid, al menos en la superficie, es un framework muy similar 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, como portales y fragmentos, transiciones de suspensión, SSR en streaming y algunas otras 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 en reactividad de granularidad fina, similar a MobX y Vue. Sus componentes solo se renderizan una vez y no hay un DOM virtual. El modelo mental completo es completamente diferente. Los mismos valores, una implementación completamente diferente. Pero, ¿qué significa eso realmente? Bueno, el desarrollo web moderno durante años ha girado en torno a los componentes. Componentes de clase, componentes de función, componentes opcionales, 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 vinculados a ellos. Esto ha llevado básicamente a dos visiones del mundo. O bien se utiliza una diferencia de arriba hacia abajo como un DOM virtual o una plantilla literal de etiqueta. O, alternativamente, se depende en gran medida de la compilación para separar la creación de la actualización. Pero ambos todavía tienen componentes que se ejecutan básicamente de arriba hacia abajo. Y esto plantea la pregunta, ¿cuándo y qué memoizar? Esto es importante para el rendimiento, porque si vas a llamar 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 idea podría ser construir tu aplicación de lista de tareas en un framework como React. Algo así. Declaras un estado y lo conectas. Pero en cualquier cambio, incluso si no está relacionado con la lista de tareas, estarías volviendo a renderizar toda la lista. Pero tal vez eso esté bien. Por eso existe un DOM virtual, 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 verse así. Tal vez agregues un filtro y algunos temas.

Y no hay nada inherentemente malo en esto. Pero ahora estamos anotando cosas con memo, use memo y use callback. Y agregando nuestras matrices de dependencia y asegurándonos de que todo se ejecute exactamente como queremos. Pero es un poco diferente a cómo comenzamos.

Entonces... Vamos a compilarlo. Y esto es lo que podrías obtener. Para ser justos, este no es el código que escribirías, es el resultado compilado, una especie de pseudo-código, del 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. Son una serie de comprobaciones de igualdad referencial poco profundas que, en cada punto de decisión, se vuelven a ejecutar cuando se marca tu componente como necesitando una actualización. El punto en común es un estado de actualización del componente, luego se ejecuta una función de actualización y se verifica contra estos valores memorizados, como se muestra aquí en esta memcache.

Pero, ¿y si no lo hiciéramos? ¿Y si solo ejecutamos lo que se necesita y no dependemos mucho 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 un poco al principio. Y voy a volver todo el camino al principio. Recuerda, el primer programa que escribiste. Era un Hola, Mundo. Pudiste establecer algunos datos en una variable y mostrarlos en la consola. Y no pasó mucho tiempo antes de que te dieras cuenta de que podías establecer un nuevo valor para esa variable y mostrarlo nuevamente. 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 de saludo aquí, y podemos tener un seter name y luego llamar al saludo, y luego seter name y llamar al saludo nuevamente. Y 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 en juego la reactividad.

La reactividad se basa en primitivas. Es como una promesa en JavaScript. En nuestro caso, vamos a introducir la primera primitiva aquí, y se llama señal. Las señales son relativamente simples. Son solo un envoltorio sobre un valor. Tienen una función de obtención de nombre aquí y un seter, set name. Y en este caso, tenemos que reemplazar esta asignación que tenemos aquí ahora con set name para poder actualizarlo. Y necesitamos reemplazar nuestro nombre. Ahora necesitamos llamarlo, porque es una función. Y una vez que hemos hecho eso, básicamente actúa de la misma manera. Todavía podemos ver Hola Mundo y Hola Solid JS.

Eso en sí mismo, para ser justos, no es muy interesante. Así que tenemos otra primitiva que vamos a elegir aquí llamada create effect. Y lo que hacen los efectos es que nos permiten interactuar con nuestro mundo cada vez que una señal cambia. En este caso, vamos a tomar nuestro console log y vamos a ponerlo en el efecto y hacer que escuche a name. Esto nos permite limpiar el resto de este código, básicamente. Así que ahora solo creamos nuestra señal para el nombre y luego creamos el efecto que se ejecuta una vez. Y luego, cuando establecemos el nombre nuevamente, se ejecuta nuevamente. Y nuevamente, esto se debe a que llamamos a names una función que nos permite interceptar la lectura de ese valor. Y esto puede extenderse fuera del efecto en sí porque esto no es un truco del compilador. Esto es completamente runtime. Entonces podemos hacer algo como mayúsculas y ahora básicamente podemos llamar a nuestro nombre aquí y cambiarlo a mayúsculas, ponerlo en nuestro efecto. Y debido a que solo usa la pila de runtime, ahora podemos ver hola mundo y hola solid js en mayúsculas. Entonces te preguntarás cómo funciona esto. Y todo se reduce a esta idea de la reactividad de granularidad fina. Crear una biblioteca reactiva de granularidad fina se puede hacer en aproximadamente 50 líneas de código.

Voy a simplificarlo aún más aquí con fines de demostración, pero todo comienza con señales como vimos. Y en su núcleo, simplemente ves una señal 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 una suscripción.

Entonces actualicemos nuestras señales, hagamos un poco más. Ahora, al leer, lo que queremos hacer es verificar si hay un observador actual. Y si lo hay, lo agregaremos a un nuevo conjunto de suscriptores que creamos cuando creamos nuestra señal. Al escribir, actualizamos nuestro valor aún, pero ahora realmente iteramos sobre esos suscriptores y los llamamos para notificarles básicamente que algo ha cambiado. Y ese algo que debe ser notificado son nuestros efectos, que son el otro lado de nuestra ecuación.

Aquí puedes ver la implementación para obtener el observador actual. Lo que tenemos es una pila. Este contexto es solo una matriz, contexto global. Y simplemente tomamos lo que está en la parte superior de la matriz para ver qué se está ejecutando actualmente. Para nuestro efecto en sí, cuando se crea, se ejecuta de inmediato. Y luego pasa por el ciclo de limpiar las dependencias o suscripciones, se empuja a sí mismo en esa pila, para que cuando ejecutemos la función proporcionada, esté allí y se pueda agregar a las suscripciones. Y finalmente, se desapila a sí mismo. Voy a poner el código lado a lado, para que puedas ver esto mejor a medida que revisamos nuestro ejemplo. Básicamente, creamos nuestra señal, como nuestra señal de nombre, y devuelve nuestras funciones de lectura y escritura. Luego creamos nuestro efecto. Se ejecuta, se empuja a sí mismo en esa pila. Luego se ejecuta la función y lee desde nuestra señal de nombre, momento en el que ve el observador actual, que es ese efecto, y lo agrega a sus suscriptores. Luego lo registra en la consola y el efecto termina de ejecutarse, desapilándose a sí mismo. En algún momento posterior, se actualiza nuestra señal, lo que establece el nuevo valor y luego ejecuta nuestra lista de suscriptores. En este caso, es ese efecto, que lo ejecuta nuevamente, limpiando las dependencias y simplemente comenzamos todo el ciclo nuevamente. Y eso es realmente todo. A partir de ahí, podemos construir una base para otras primitivas. Muchas de ellas no son esenciales. Se pueden usar según sea necesario, pero un ejemplo de algunas importantes que se incluyen en Solid son createMemo, que se puede usar para almacenar en caché cálculos costosos, createStore, que es un proxy que permite la reactividad profunda anidada, y createResource, que es nuestra primitiva de primera parte para la obtención de datos y suspense. Pero basta de reactividad por ahora. Volvamos a nuestro ejemplo.

Cuando enseñamos reactividad, siempre usamos console logs, pero hagamos algo un poco más sustancial aquí. Esta vez, vamos a crear un elemento DOM y ver qué hace. Así que lo que vamos a hacer aquí es crear un encabezado y establecerle un texto, y luego lo vamos a adjuntar al DOM.

Y luego vamos a tomar esa configuración de texto y ponerla en el efecto. Así que ahora, cada vez que cambie el nombre, se actualizará el DOM. En este caso, establecemos Solid.js de inmediato, por lo que ni siquiera lo vemos. Solo vemos `hello Solid.js` porque se actualizó de inmediato. Así que lidiemos con eso.

Creemos un botón y pongamos el setter dentro de un controlador de clic. Estamos utilizando las API DOM básicas aquí para que funcione. Y ahí lo tienes. Ahora nuestro `Hello World` tiene un botón de saludo y cuando hacemos clic en `greet`, cambia a `hello Solid.js`. Pero quiero decir, esto es mucho código. ¿Quién quiere escribir todo ese JavaScript básico? ¿No sería genial si pudiéramos simplemente escribir algo como JSX? Y en Solid, puedes hacerlo porque JSX y Solid son simplemente elementos DOM. Así que este es un verdadero elemento de botón HTML que estamos creando aquí y simplemente vamos a poner un controlador de clic en él, limpiar ese código y nuestro ejemplo sigue funcionando. Y podemos darle el mismo tratamiento al encabezado. La única diferencia aquí es que el encabezado tiene una declaración reactiva y el compilador de Solid puede ver que estamos llamando a una función en la expresión, por lo que sabe envolverla automáticamente en un efecto. Y cuando hacemos eso, funciona perfectamente. Y es un poco más limpio aquí, pero en realidad no escribimos nuestras aplicaciones de esta manera. Así que abstraigamos 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 llamar a nuestra función y simplemente adjuntarla. Y como puedes ver, claramente sigue funcionando. Pero vamos a incrustar el JSX un poco más, limpiar un poco más, eliminar todo eso y luego formatearlo con prettier. Y aquí lo tienes. Bien. Podemos reemplazar el array con un fragmento porque eso es todo lo que son los fragmentos en Solid. Y esto comienza a verse bastante bien.

Lo último con lo que realmente tenemos que lidiar ahora es cómo nos estamos conectando a los DOM. Solid proporciona una función de renderizado y simplemente podemos renderizar nuestro componente de saludo y ahí lo tenemos. 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 saludo, digamos saludo. Y verás un registro cuando lo presione, no se registra nuevamente. Solo se registra una vez. De acuerdo. Así que hagámoslo una vez más. De acuerdo. Aquí estamos. Hola mundo. Ve a saludar, presiónalo. Solo una vez. Y sí.

Ampliemos esto un poco más. Usemos realmente dos componentes de saludo ahora. Los vamos a poner dentro de un componente de aplicación que usamos. Y al hacer esto, puedes ver que cada componente puede envolver su propio estado. Así que ahora tenemos dos, podemos ver que registra el saludo en la consola dos veces ahora, pero cuando actualizamos cada uno, no se registra nuevamente y se actualizan de forma independiente, manteniendo cada uno 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 desde la misma variable, como funciona en JavaScript. Y efectivamente, no importa qué botón presiones, actualizan el mismo estado y los registros de la consola solo se registran al crear y actualizar. Pero la mayoría de las veces vas a poner esto en props. Así que pongámoslo en la aplicación y pásalo como props. 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 de entender aquí, sin embargo, es solo donde está el texto del encabezado, eso es lo que realmente se actualiza. Estamos compartiendo el estado hasta aquí, pero los componentes solo se ejecutan una vez.

Entonces, este registro de consola de la aplicación mostrará que incluso cuando lo actualicemos, no se registrará nuevamente. Y para dejarlo más claro, voy a tomar este nombre establecido y en realidad lo voy a incrementar de manera diferente para cada componente, aunque esté utilizando el estado compartido. Aunque estamos pasando todo a través de él, cuando realmente realizamos una acción, solo hay dos efectos en toda esta página y esos son para actualizar ambos encabezados con ese texto.

De acuerdo. ¿Qué está sucediendo aquí? Bueno, es debido a la forma en que manejamos las props de los componentes. 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 forma perezosa. Es muy similar a lo que hacemos con los elementos del DOM, donde si vemos algo que podría ser reactivo, lo envolvemos en un efecto. Básicamente, todo se evalúa de forma perezosa hasta el efecto final, que es el que realiza el trabajo. Y como dije, solo hay dos efectos en esa demostración. El único trabajo que se realiza es actualizar ese único nodo de texto dentro de cada encabezado. Nada más se reejecuta.

Lo último que probablemente necesites saber sobre el renderizado en Solid es que estamos tratando con nodos reales del DOM. Y la creación puede ser derrochadora. Así que necesitamos hacer un manejo especial para cosas como las listas. Un simple array.map nunca recorrería cada elemento y mapearía nuevos resultados. Y no queremos crear nodos del DOM completamente nuevos cada vez que agregamos 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 componibles al igual que el resto de los primitivos en nuestro sistema. ¿A qué me refiero con componibles? Bueno, supongamos 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 importemos y ahora solo cambiamos nuestro componente for. Y como puedes ver, es exactamente el mismo patrón. Las listas se convierten en listas paginadas o virtualizadas. Las condicionales se convierten en diseños o suspensos o límites de error. Es todo lo mismo.

Ya 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 armados con esto, podemos volver completamente al principio con nuestro ejemplo de lista de tareas.

Así que he recreado ese ejemplo en Solid que vimos al principio, y tenemos una lista de tareas y tenemos un controlador que puede, hemos configurado nuestro estado de nuestras tareas y tenemos un controlador que actualizará nuestras tareas a completadas. Y lo que hemos hecho aquí es que realmente estamos pasando un filtro de visibilidad y un selector de color. Y esto se pasa hasta nuestro agregar tareas para establecer el tema. Así que esto agrega un poco más de complejidad o eso pensarías, pero en el caso de Solid, sin necesidad de agregar memorias o use callback o básicamente, o matrices de dependencia o básicamente cualquier cosa adicional, podemos simplemente tomar nuestra lista, filtrarla en función de esa prop y solo tener las cosas que necesitan actualizarse, actualizarse. Por ejemplo, cuando hacemos clic en este tres, ahora lo actualizaremos a por hacer 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 atrás, bueno, vamos a tener que recrear esos tres elementos. Sí, llamamos al filtro nuevamente y actualizamos tres veces, pero esta prop que se pasa aquí para el color del tema, al cambiar esto, no causa que se actualicen las tareas o el filtro. Simplemente funciona. Y hicimos todo esto 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 se actualiza muy poco. Esto es lo que sucede cuando tienes un renderizado y actualizaciones detallados.

Para mí, esto es lo que llamo la ventaja reactiva. Básicamente, los componentes se ejecutan una vez. No hay reglas de gancho o cierres obsoletos o matrices de dependencia en ese sentido. Las plantillas se compilan en nodos reales del DOM. Esto es una abstracción muy baja sobre el DOM. Significa que tienes esa salida de escape. Si necesitas hacer algo con el DOM, está ahí mismo. Pero lo más importante es que el estado es independiente de los componentes. Los límites del componente son para tu beneficio y para organizar tu código como desees. No se trata de performance. El performance es bueno independientemente. Así que si quieres experimentar la libertad tú mismo, tal vez pruebes SOLID. Gracias.