Todo lo que tenes que saber para pasar de React a Svelte

Sin lugar a duda React es la librería que mas mercado acapara en el mundo del Frontend. Sin embargo, a veces queremos expandir un poco nuestro stack o simplemente aprender nuevas cosas por curiosidad. Hoy en día mi recomendación es que aprendas Svelte y no tanto Vue o Angular que suelen ser las alternativas mas conocidas. ¿Por qué? Angular y Vue ya existen hace mucho tiempo y si miramos la tendencia de uso, nunca se arrimo a React, de hecho, en algunos casos la diferencia sigue incrementado

Svelte por otro lado es un framework relativamente nuevo que trae algunos cambios radicales que personalmente creo están buenos.

¿Vos me estas diciendo que deje React?

No, como ya mencione antes React es sin duda la librería que acapara gran parte del mercado y parece que se va a mantener así por mucho tiempo mas. Sin embargo codear solo en React hace que en un punto tengamos una visión de túnel y pensemos que la solución que plantea la famosa librería es la única correcta para resolver nuestros problemas. Sumado a eso, mantenerse fresco y conocer alternativas va a hacer que si en algún momento React pierde el trono que hoy en día tiene, podamos pivotear a otra tecnología con mayor velocidad.

Programo en React hace 3 meses, ¿me recomendas que también aprenda Svelte?

No. Si estas hace poco en el mundo de Frontend te diría que te mantengas 100% con React o con frameworks que se complementen con el mismo (como por ejemplo NextJS), eso va a ser lo que te va a dar trabajo más rápido y puedas aprender un montón de cosas que de otra forma no vas a aprender. Una vez que te sientas cómodo con ambas cosas y tengas bastante experiencia te convendría aprender otra cosa. Teniendo en cuenta eso en lo que queda de este post voy a hablar asumiendo conocimientos de React.

Cambios tecnológicos que tenes que conocer

El objetivo de Svelte es crear interfaces desde un enfoque distinto a lo que teníamos hoy en día. Por ende, nos vamos a encontrar con muchos cambios bastante fuertes comparados a lo que acostumbramos pero también vale mencionar que en algunos aspectos las cosas se mantienen similares. Pasemos a analizarlas:

No mas Virtual DOM

Wait, what? ¿No es Virtual DOM lo mejor del mundo y mas rápido que el DOM real? La respuesta es NO. Virtual DOM termina usando el DOM real para renderizar nuestra página. El motivo por el que este se volvió tan popular es que hace un diff entre la nueva modificación y el DOM actual y solamente actualiza esa parte en lugar de actualizar absolutamente todo el DOM.

El enfoque que toma Svelte con respecto a esto es resolverlo en build time. Esto quiere decir que vamos a tener un compilador que va a transformar nuestro código .svelte en código javascript el cual va a hacer las actualizaciones derecho contra el DOM real (como por ejemplo crear un nuevo nodo, cambiar el valor de un atributo, borrar un nodo, etc). En síntesis deja de existir el concepto de "re-render" para absolutamente todo el componente.

No mas JSX

Svelte usa directamente un sistema de templating por lo que nuestro código se va a ver algo mas parecido a los inicios de NodeJS cuando usábamos handlebars o jade. Personalmente esto es algo que no me super encanta de Svelte ya que conceptualmente en JSX nosotros estamos en el mundo de Javascript lo que nos da varias libertades y estandarizaciones que un sistema de templating no. Por ejemplo, si nosotros queremos iterar sobre un array en JSX podemos usar map que es algo a lo que ya estamos acostumbrados

Mientras que en Svelte tendríamos que utilizar #each as que es la manera que nos plantea su sistema de templating. Se vería algo así:

Leyendo un poco mas sobre porque tomaron esta decisión, una de las razones que encontré fue que es mas fácil analizar el código de forma estática en un sistema de templating que son reglas bien definidas que en algo como JSX que es un mundo mucho mas extenso y difícil de controlar. Por lo que esta decisión esta estrictamente relacionada con el punto que charlamos antes sobre la inexistencia del virtual dom.

Reactividad

La reactividad es por lejos uno de los puntos mas importantes dentro del mundo de Svelte ya que es el mecanismo que usa para mantener sincronizado el DOM con el estado de la aplicación. El ejemplo mas clásico para demostrar esto es el siguiente

Esta mecánica funciona muy bien cuando queremos actualizar el DOM en base a una actualización de estado (en nuestro ejemplo, el cambio de la variable count). Sin embargo, a veces tenemos que actualizar nuestro estado basandonos en otras variables de estado que cambian durante el flujo de nuestra aplicación. Por ejemplo, pensemos el caso en donde queremos imprimir en pantalla el doble de la cantidad de veces que clickeamos un botón. En base a lo que vimos el primer código que podríamos pensar es el siguiente:

Pero si lo probamos nos vamos a encontrar con que el valor de double sin importar cuantas veces hagamos click va a ser 0. Esto es porque por defecto, svelte no actualiza el valor de count en todos los lugares donde se use salvo que nosotros explícitamente se lo digamos. Ahí es donde entra en juego el símbolo $ el cual indica que hay que hacer un re-render de esa variable cuando cualquiera de sus referencias cambie. El código se vería algo así:

Ciclo de vida de un componente

En este punto svelte es bastante parecido a React, tenemos cuatro métodos: onMount, onDestroy, beforeUpdate y afterUpdate.

Capacidad de tener estado centralizado

Svelte viene por defecto con una funcionalidad llamada stores los cuales nos van a ahorrarnos los eternos callbacks que hacemos en React cuando buscamos pasar información "hacia arriba". Si bien hay muchísimos detalles para hablar en este punto, su funcionamiento se basa en tener un lugar en donde podemos guardar una serie de métodos e información que vamos a poder importar desde donde sea en nuestra aplicación para llamarlos. Sumado a eso también tiene un método subscribe que nos va a avisar cada vez que algún valor de ese store cambie. En este punto creo que el ejemplo que tiene la propia documentación de svelte es bueno, así que para no repetir información pueden ir a verlo directamente acá: https://svelte.dev/tutorial/writable-stores

Context

Sumado al estado centralizado. Svelte tiene una Context API que funciona prácticamente igual al de React. Existen dos métodos getContext y setContext. Un error muy común es pensar que el concepto de Context y Store son iguales lo que nos hace pensar que no tiene mucho sentido que Svelte tenga ambos. Sin embargo, la principal diferencia es que los stores son accesibles desde cualquier parte de nuestra aplicación mientras que nuestro contexto solo se puede acceder desde el componente que se genera hacia abajo por lo que no es compartible "entre hermanos". Esto puede parecer trivial pero el uso correcto de los mismos hace que el scope de nuestra información este mejor segmentada.