Solid.js es una nueva biblioteca que es muy parecida a React
y ahora lo vamos a comprobar que es muy parecida a React
y como dice aquí, pues es una biblioteca para construir
interfaces de usuario que es declarativa, eficiente y flexible.
Este claim, digamos este subtítulo, creo que se parece un poco al de React, ¿no?
A JavaScript Library for Building User Interfaces
pues es JavaScript Library for Building User Interfaces
solo que es declarativa, eficiente y flexible.
Que aquí tenemos declarativa, componentes y bueno, que la aprendes una vez y ya lo tienes.
Es bastante parecido y vais a ver que los parecidos no acaban aquí.
Esto es solo el inicio de las cosas que están parecidas.
La gran diferencia está en esta negrita que dice que Solid es una biblioteca puramente reactiva.
Lo cual es muy curioso, ¿no? Porque React se llama React que parece de ser reactivo
y al final React no es tan reactiva como dice ser.
Y ya entenderéis un poquito estas diferencias, ¿vale?
Tenemos aquí que dice puramente reactivo, que ha sido diseñada desde cero, ¿vale?
Para que su core sea reactivo y construido para tener herramientas
que estén bien hechas en un ecosistema que va creciendo.
O sea que se enfoca mucho en la performance.
Vais a ver ahora luego una comparación que es muy potente.
Pone que es pragmático. Ahora veréis esto del pragmatismo y productivo, ¿vale?
¿Qué es lo bueno que tiene? Bueno, aparte que dice que tiene 5 años de desarrollo
y que tiene soporte para TypeScript y que tiene muy buena performance con soporte para Astro y tal.
Pues esto, que ocupa 6K. Es una brutalidad esto.
O sea, solo para que hagamos una diferencia, ¿vale? Rápida.
Vamos a ver si encuentro, creo que es solid, make small, creo que es solid.js.
Creo que es este, ¿no? ¿Vale? Son 6K.
Si comparamos, porque claro, si lo comparamos con React, parece que son 3K.
Pero es que no hay que compararlo con React.
Habría que compararlo con el React DOM, ¿vale?
React DOM más React. Hay que sumar los dos.
Así que la diferencia ya ahí se hace bastante más importante, ¿vale?
O sea, son 6K, lo que sería React más React DOM, ¿vale?
No lo comparéis, o sea, no comparéis solo la parte de React porque siempre necesitáis los dos.
Entonces, Solid lo que es, es una biblioteca que hace todo lo que hace React,
pero con un enfoque muy claro al tema de la reactividad.
¿Y cómo se traduce esto? ¿Vale?
Pues se traduce con que podemos ver este código, este código de aquí,
no sé si lo puedo hacer un poco más grande, ¿vale?
Este código aquí parece, se parece mucho, mucho, mucho, se parece mucho a React, mucho.
O sea, import render de Solid.js web, esto sería React DOM, ¿vale?
Import on cleanup y create signal, esto sería limpiar un efecto y esto sería, pues, un use state, ¿vale?
Pero en lugar de Solid.js sería React.
Y aquí podemos ver el componente, esto se parece mucho a un use state.
No hay un use effect, que esto es una cosa que veremos ahora, pero se parece mucho, ¿vale?
Se parece mucho. Hay una diferencia, por eso dice que es familiar y moderno.
O sea, se han basado muchísimo en React, muchísimo.
O sea, la copia es muy evidente.
Estoy empezando con React. Me está diciendo que le dije que me vaya Solid porque te hago caso, ¿eh?
No, Arkea. Estoy diciendo...
Mucha gente dice que es el asesino de React, pero ya te digo yo que no, ¿vale?
Ya te digo yo que no.
¿Qué es interesante? Sí.
De hecho, aquí tenemos un tema de rendimiento donde podemos ver que un código hecho en Vanilla, pues, digamos que tiene una puntuación de 1 y Solid tardaría 1.05, ¿no?
Donde tarda Vanilla un segundo, por ejemplo, Solid tardaría 1.05 y React tardaría el doble.
O sea, que en temas de rendimiento es bastante más performante Solid que todas las alternativas.
Incluso que Svelte, que mira que Svelte es súper rápido.
Pues, mejor que Vue, que React, que Angular, mejor que todos estos, se supone que es lo más cercano que hay a Vanilla JavaScript.
Que se supone que Vanilla JavaScript es lo más rápido que puede llegar a ser una cosa.
Obviamente, el que sea más rápido no significa que sea mejor per se.
Porque, claro, Vanilla, por ejemplo, suele ser lo más rápido, pero luego tienes que escribir muchísimo código.
Hay que tenerlo en cuenta, ¿vale?
Entonces, tiene un montón de features, pero si me pongo a leer las features, vas a ver que estoy hablando de React.
Fragments, portals, context, suspense, todo esto, todo esto, casi todo, casi todo, porque las directivas no.
Pero casi todo lo que vemos aquí es un tema de cosas que tiene React.
Así que vamos a hacer el Getting Started, vamos a ver un poco el código, vamos a echarle un poquito de vistazo y a ver cómo funciona esto.
Y luego, si tenemos dudas, le damos al tutorial y vemos cómo funciona.
Además, también tienen ejemplos, así que nos puede venir bien, porque vais a ver que tiene cosas que hay que acostumbrarse.
Hay que acostumbrarse y hay que hacer un cambio de chip muy importante, porque tiene grandes diferencias.
Venga, voy a ejecutar este código, que este código al final lo que hace es utilizar un template de Vite para que se instale, ¿vale?
Ey, Lea Ciber, gracias por la write de 21 participantes, estamos aquí aprendiendo justamente, vamos a empezar ahora a instalar SolidJS.
Así que, bienvenutis y vamos con ello.
My first SolidJS app, ¿vale?
Vamos a darle.
El DGit, para el que no lo conozca, esto es un comando que creó Svelte.
Mira, de hecho, el creador de Svelte, de este comando de DGit, hablo en mi libro de aprendiendo Git, hablo de este comando, justamente.
Qué casualidad.
My first SolidJS app.
¿Vale?
Esto lo que hace el DGit es clonarte un repositorio, pero sin crear el repositorio de Git.
Entonces, lo que hace es descargar los archivos, es como cuando vas a un repositorio de GitHub y le das a descargar, mira, te vas aquí y tú aquí le puedes dar Download Zip.
Pues es exactamente lo mismo, pero en la carpeta en la que estés.
Es bastante útil.
Ahora que ya tenemos esto, hostia, PNP, PNPM, madre mía.
Vamos a ver, espero que no me dé problemas con NPM Store y que no me obliga a utilizar PNPM.
¿Publicidad de libro encubierta?
No, hombre, cuando hago publicidad la hago bien de hecha, la hago bien hecha.
Vale, 8 segundos, no está mal.
Venga, NPM Run y vamos a dar NPM Run Def.
Y aquí, en el localhost 3001, ya tenemos nuestra aplicación de Solid dando vueltecitas.
Venga, voy a ponerlo aquí a un ladito y voy a abrir esto, este editor.
Esto por aquí, esto por aquí.
Y vamos a ver un poco, vamos a curiosear qué está haciendo Solid.
¿Vale?
Tenemos aquí nuestro proyecto, lo acabamos de crear, aquí la configuración de Vite.
Si no sabes que he hablado mucho de Vite, pero es una alternativa a Webpack, solo que mucho más rápida que Webpack.
¿Vale?
Un Ritmi, este archivo lo podemos ignorar porque es de PNPM, que es una alternativa de NPM, pero no la estamos utilizando.
El Package JSON, donde ya hemos visto que tenemos los scripts para ejecutar y levantar el proyecto, ¿vale?
Con la dependencia que necesita y la dependencia de Solid.js, que es la biblioteca de UI que estamos mirando.
El index.js no tiene absolutamente nada, solo tiene esto, lo importante, que carga el source index.js.
Ya vemos una cosa súper importante de Solid.js, que también utiliza Solid.js, también utiliza JS.
¿Vale?
Y es que vais a ver que se parece mucho a React, mucho.
Ya tenemos aquí en source, tendríamos el logo, que es el que está dando vueltas, y el index.js, que este sería el punto de entrada de nuestra aplicación.
Para que veamos un poco cómo funciona desde cero, lo que voy a hacer es comentarlo, voy a refrescar, ahora esto nos sale totalmente vacío,
y voy a hacer desde cero, voy a hacer un poco lo que tenemos que hacer paso a paso, ¿no?
Lo primero que tenemos que hacer es importar el método render desde Solid.js barra web, y ahora le tendríamos que decir
dónde queremos renderizar el componente de Solid.js.
Ahora mismo no tengo ningún componente, así que voy a hacer un render, vamos a probar a poner un h1 con holaSolid.js,
y como segundo parámetro hay que decirle dónde queremos que lo renderice.
Le podríamos poner el document body, o sea, que todo el body lo renderice con esto, a ver si cuela.
Parece que no cuela, no ha colado. Vamos a probar con el gtlm en by id.
A ver, gtlm en by id.
Tampoco cuela.
No cuela, y me parece que es porque hay un tema diferente, vamos a ver un momento los errores que está dando esto,
pero me parece que hay un tema diferente en cuanto a cómo funciona el render del React DOM y el de Solid.
Vamos a verlo.
Code is not a function.
¿Qué code?
Me parece, puede ser, puede ser, porque veo aquí la diferencia, aquí en este que he comentado aquí,
que haya que pasarle, aquí si te fijas en el render le pasa app, pero no le pasa como este, este app, ¿sabes?
Le pasa directamente el elemento.
Igual, igual es que hay que pasarle un elemento.
A ver, si por ejemplo ponemos app, y esto hacemos que vuelva al h1 de hola solid.js,
y le decimos que queremos renderizar aquí, en lugar de esto.
Le pasamos directamente el componente, en lugar de un elemento.
Ahora sí.
O sea, que hay que pasarle el componente, no un elemento.
Esto es algo diferente al React DOM, porque en el render del React DOM se le puede pasar justamente el elemento.
No hace falta pasarle directamente el componente.
Esto es diferente.
Una pequeña diferencia, pero bueno, importante diferencia.
Así que ya podemos quitar todo esto, y podemos iniciar un poquito.
¿Qué he hecho aquí?
Importar el render de Solid.js.
Esto sería nuestro componente app, ¿vale?
El componente app, al final lo único que hace es renderizar un h1 que ponga hola solid.js,
y utilizamos el método render, este método render del Solid.js web,
para renderizar el componente app en el elemento root.
¿Dónde está este elemento root?
Pues en el index.html, aquí tenemos el elemento root.
Si aquí pusiese elemento app, pues tenedlo en cuenta que hay que cambiarlo aquí, ¿vale?
Habría que poner aquí app.
Que hay mucha gente que se cree que esto sale de la nada, y no.
Está en el index.html.
Una cosa que se hace a veces, en algunas, es utilizar directamente el document.body.
Pero bueno, si esto lo bueno es que te machaca todo lo que habría aquí, que puede ser una opción.
Pero bueno, solo que lo tengas en cuenta, normalmente se utiliza así,
pero si te quieres quitar un nivel de anidación, podría ser una.
Bueno, pues esto es Solid.js por ahora, ¿vale?
Ahora mismo no es que tenga mucha historia.
Vamos a intentar utilizarlo un poquito por encima.
Vamos a hacer el primer ejemplo más típico, pero que ya va a empezar a ayudarnos a ver la diferencia que hay con React, ¿vale?
La primera sería utilizar createSignal, ¿vale?
CreateSignal.
Y este CreateSignal lo tenemos que importar de Solid.js.
¿Qué es este CreateSignal?
Pues mirando un poquito esta documentación, lo que podemos ver es que el CreateSignal lo que tiene es que es como un UseState, ¿vale?
Aquí tendríamos First, SetFirst, CreateSignal.
Es que se parece tanto.
O sea, es que se parece mucho.
Se parece mucho.
Entonces, fíjate que en el primero nos devolve parece el valor, pero no es así.
Y en el segundo nos devolve cómo actualizar ese estado.
Vamos a utilizarlo, ¿vale?
Para que lo veamos más claro.
Ahora, tendríamos, vamos a poner esto por aquí, esto por aquí, esto por aquí.
Y aquí vamos a poner el Counter y el SetCounter.
Vamos a hacer un contador, que es que sé que es lo más típico, pero es que así lo vamos a ver clarísimo.
A ver, voy a quitar este proyectillo que tengo por aquí, fuera.
Aquí tengo un montón de proyectos siempre.
Mira, Cody Link también lo tengo abierto.
Este lo vamos a dejar por aquí.
Lo vamos a poner por aquí.
Y este lo vamos a dejar por aquí, ¿vale?
Y aquí vamos a hacer el Return de esto, ¿vale?
Por ahora, ¿qué es lo que voy a querer?
Bueno, pues si es un contador, vamos a intentar renderizar el contador y vamos a poner el botón y todo esto.
¿Vale?
Vamos a poner, vamos a utilizar el Fragment, ya que decía que se podía utilizar un Fragment, ¿no?
Nuestro contador, vamos a poner aquí en Contador, el Counter.
Y vamos a poner un botón que cada vez que se haga un clic, por ahora no haga nada.
Vamos a poner aquí el increment, ¿vale?
Vamos a poner aquí una función vacía que no haga nada.
Fíjate que es que se parece demasiado, se parece demasiado.
O sea, es que es exactamente igual a React.
Vale, aquí me ha puesto un 0, ¿no?
Si yo pongo aquí un 5, me pone un 5.
O sea, parece que funciona exactamente igual a como funciona React, ¿vale?
Pues vamos a hacer que cuando haga el onClick este, lo que vamos a hacer es ejecutar el SetCounter
y vamos a contar, vamos a hacer que el contador sea ahora Counter más 1, ¿vale?
¿Vale?
Pues ya estaría.
O sea, ahora mismo está funcionando.
O sea, esto podría ser React y no habría ningún tipo de diferencia.
Ninguna diferencia.
O sea, sería exactamente lo mismo.
Vamos a ponerle un poquito de estilos, si os parece, para que PhoneFamily, nuestro contador.
Voy a importar los estilos estos del index.import.index.css.
Ah, vale.
Esto así, en relativo.
Perfecto.
Y vamos a poner...
A ver, esto está dentro de app, ¿no?
Pues app.
Esto así.
Vamos a poner display grid.
Vamos a poner container medio.
Esto que tenga como mínimo esto.
Y al menos que salga un poco por aquí.
Vamos a poner un poquito más de esto.
Y ya tenemos nuestro contador.
Vamos a poner el botón que también tenga el font size de 24 píxeles.
Un poquito.
Vale.
Pues ahora mismo está funcionando exactamente igual.
O sea, es exactamente lo mismo.
Es exactamente lo mismo.
¿Cuál es la diferencia?
Pues en realidad no hay ninguna diferencia ahora mismo.
No hay ninguna diferencia.
Vamos a intentar hacer otra cosa con nuestro contador, ¿vale?
En React, cuando tú vuelves a renderizar algo, podríamos ver si el número es par o impar.
O sea, podríamos poner aquí, por ejemplo.
Vamos a poner otra p y vamos a poner que counter, si es divisible entre dos...
O sea, si es divisible entre dos, significa que el resto es cero.
Pues esto es par y si no es impar, ¿no?
¿Vale?
Vamos a dejar esto aquí, que lo evalúe.
¿Vale?
Es impar.
Aquí hay un problema.
Esto es diferente justamente a React.
¿Siempre tienes que pasarle una función a setCounter?
No.
En este caso se le puede pasar exactamente como lo estábamos haciendo antes.
Pero seguramente vamos a tener problemas.
De hecho, efectivamente, vamos a tener problemas.
¿Por qué?
¿Por qué?
¿Por qué vamos a tener problemas?
¿Qué está pasando aquí?
¿Cuál es la diferencia?
¿Aquí hay algún problemilla?
Sí hay un problemilla.
Y es que una de las grandes diferencias con React es que este CreateSignal nos devuelve dos elementos.
Un array de dos elementos.
El primero no es el valor.
No es el valor.
Es muy raro, pero no es el valor.
Claro, lo raro es que todo parecía funcionar correctamente.
¿Vale?
Todo parecía funcionar correctamente.
Pero ahora mismo me estoy dando cuenta de algunos errores, ¿no?
Primero, este es impar, no está cambiando nunca.
No está cambiando.
Luego, este sí que funciona, parece.
Pero aquí, en el setCounter, estoy usando un callback.
Si, por lo que sea, intento utilizarlo directamente así y hago setCounter, que sea counter más uno,
fíjate que si guardo los cambios y le doy un increment, me dice que esto es una función.
Y yo, ¿pero esto qué es?
¿Cómo que es una función?
Bueno, porque el CreateSignal y cómo funciona SolidJS es totalmente diferente a React.
Y aquí, este pequeño cambio es el que desbloquea un montón de divergencias, algunas incluso problemáticas.
Si tienes el mindset de React, me refiero no a problemática per se, pero tienes que saberlas, porque si no te puede causar muchos problemas.
Y el hecho, el hecho es que aquí este CreateSignal, lo que vamos a tener en el primer elemento, no es el valor, sino que es una función para recuperar el valor.
¿Qué significa esto? Pues que esto no es counter, esto es getCounter, ¿vale?
Y esto es una función que tenemos que ejecutar cada vez que queramos recuperar el valor del counter.
¿Vale? getCounter, la ejecutamos aquí.
Y aquí podríamos hacer esto también.
getCounter.
Vamos a ver si ahora esto funciona mejor, ¿vale?
Ahora podemos ver que sí que funciona.
¿Qué está pasando? ¿Por qué pasa esto?
¿Por qué pasa esto?
Y esto es lo más importante.
Mira, vamos a hacer este ejemplo en React y lo vamos a hacer en un momentito en CodeSandbox, si os parece.
Y os enseño la diferencia básica que hay entre Solid.js y React y por la que Solid.js mucha gente le está dando bastante bombo.
¿Y a qué se refiere Solid.js cuando dice que es realmente reactivo?
Lo vamos a ver ahora.
Vamos a intentar exactamente lo mismo con React.
Esto lo vamos a arreglar, ¿no?
Ponemos aquí que esto viene de ReactDOM.
De ReactDOM.
El CreateSignal sería el UseState.
Esto será un React.
¿Vale?
Aquí esto es un UseState.
El GetCounter, esto directamente sería Counter.
Y esto lo quitamos de aquí, lo quitamos de aquí.
Y esto igual, ¿vale?
Counter lo quitamos de aquí.
Bueno, en el index.js esto no es importante.
Vamos a ver en el HTML.
Public.
Esto aquí será root.
Vale, es un momentito.
Así que ponemos aquí el root.
Y esto, aquí lo que espera es un elemento.
Expect a string.
Espérate.
Ah, no.
A ver, a ver.
Ahora.
Simvalid expect a string.
Espérate que algo aquí la he liado.
Por aquí.
Ay, es que esto no lo he puesto en el index, perdón.
Es que esto va aquí.
Ahora sí.
Es que lo he puesto en el app.js.
Se estaba importando y la he estado liando.
Ahora sí.
En el index.js.
Vale.
Este ejemplo funciona exactamente igual.
O sea, parece que funciona exactamente igual.
Pero vamos a hacer una cosa.
Voy a hacer que cada vez que se renderice el componente,
porque aquí es donde está la gran diferencia, ¿no?
React, lo que tú tienes en un componente,
sobre todo, bueno, en un componente funcional,
en este componente,
es que el cuerpo de la función,
el cuerpo de la función es lo que renderiza.
¿Qué quiere decir?
Que tú cuando pones aquí un console.log,
si yo pongo aquí un console.log y pongo aquí render,
fíjate, ¿vale?
Yo guardo estos cambios.
Y al final, si yo cada vez que le da increment,
¿vale?
Cada vez que le doy increment aquí,
bueno, ahora porque esto voy a limpiarlo.
Mira, cada vez que le doy aquí al increment,
no sé si lo vas a ver,
pero cada vez que le doy increment,
aquí en la consola se va a renderizar un nuevo console.log,
¿vale?
Va a poner render cada vez que le doy, ¿vale?
Un, dos, tres, cuatro, cinco.
¿Ves?
Cinco renders.
¿Cómo puede ser que se esté ejecutando este console.log?
Porque he puesto aquí un console.log
y cada vez que se renderiza el componente de React,
pues se está renderizando todo el cuerpo, ¿vale?
Todo el cuerpo de la función esta.
En cambio, en solid.js,
los componentes,
no hay que tratarlos como si el cuerpo de la función
fuese el renderizado,
sino que lo que hay que entender
es que el cuerpo de la función
es el constructor del componente, ¿vale?
O sea, que son cosas diferentes.
Solo es como que se inicia una vez.
Aquí lo que se inicia una vez solo
sería el useState.
Por eso los hooks tienen diferentes reglas.
Tú no puedes hacer que los hooks
se cambie el orden de ejecución
ni puedes hacer que esté en un condicional
porque los hooks,
este hook,
esta línea de aquí,
aunque se ejecuta,
el hook esté por dentro
ya sabe que se ha ejecutado
y dice,
ah, no tengo que hacer un useState otra vez.
Entonces, ignora lo que tiene que hacer aquí,
lo ignora
y luego lo que hace es renderizar,
ejecutar el resto del código.
Por ejemplo,
el console.log lo está ejecutando.
En cambio, en solid.js,
vamos a ver cómo pasa esto, ¿vale?
Para que vean la diferencia.
Ahora yo pongo aquí el console.log,
¿vale?
Voy a poner aquí el render,
este, el render, entre comillas.
Vamos a guardar los cambios.
Voy a abrir el...
A ver si lo tengo por aquí.
Vale, lo tengo por aquí.
Vamos a dejar nuestro ejemplo de React.
Vamos a dar con el código.
Y ahora yo,
si abro las herramientas de desarrollo,
voy a poner esto abajo,
pongo la consola,
quito esto,
vale.
Fíjate, ¿no?
El render, una vez.
Yo le voy dando
y ¿qué pasa aquí?
Que el render,
o sea,
solo ha sido una vez.
Porque esto ya no es el render.
Esto es el constructor del componente.
Y esto es lo que hace que sea realmente reactivo.
Solid.js.
El cuerpo este,
que estás viendo aquí,
solo se ejecuta una vez.
Por más veces que se renderice un componente,
solo se ejecuta el constructor del componente una vez.
Esa es la diferencia.
Pero claro,
entonces tú dirás,
bueno,
¿pero esto cómo funciona entonces?
¿Cómo está haciendo esta magia?
Claro.
Lo que está pasando aquí
es que ahora necesitas utilizar un método
para recuperar el estado.
Y utilizando este método,
lo que hace Solid.js es que es reactivo.
Y dice,
cuando cambies este estado de aquí,
voy a detectar en qué partes lo has utilizado,
¿vale?
En qué partes has utilizado esto.
Y de esta forma sabré que este counter
tiene que renderizar esta parte del código.
¿Vale?
Esto es lo que hace que sea realmente reactivo.
Y react.js no sea del todo reactivo.
Porque no reacciona del todo
a esas partes del estado,
sino que lo que hace es renderizar
todo el cuerpo de la función.
Esto tiene diferentes problemas
y te voy a explicar por qué.
No es un problema, ¿vale?
O sea,
no es un problema.
Es un...
Es una feature.
Es una feature que hay que tener en cuenta.
¿Qué problemas te puedes encontrar?
A ver,
si yo pongo aquí un counter,
getCounter,
¿vale?
Lo pongo aquí.
Y en lugar de utilizar estos getCounters de aquí,
utilizo el counter.
Fíjate lo que está pasando ahora.
Que yo le doy a incrementar
y no funciona.
¿Vale?
Waiko no tiene virtual DOM.
Solid.js no tiene virtual DOM.
Funciona exactamente igual
como lo que hace Svelte.
Pero fijaos en este problema.
Esto es un error
que os podéis cometer mucho.
Lo que está pasando aquí
es que yo estoy sacando
en una constante el counter,
¿vale?
La ejecución del getCounter.
¿Por qué?
Porque yo estoy pensando,
bueno,
cada vez que se renderiza el componente,
cada vez que se renderiza el componente,
tengo un counter
y entonces utilizo un nuevo counter
aquí,
aquí,
aquí.
Pero esto no funciona.
¿Vale?
Esto no funciona.
Yo ahora le doy a increment
y fíjate,
se queda...
Está congelado.
¿Por qué?
Porque la ejecución de este método
es lo que consigue la reactividad.
El hecho de que en todos los sitios
en los que tú pongas este getCounter
aquí,
aquí y aquí,
es que va a detectar
que tiene que cambiar esa parte.
Es que tiene...
Sabe ha identificado
que en JSX
este elemento
tiene que volver a renderizarse.
Esto es súper importante
y esto es una de las razones
que lo hace muy potente,
pero también lo hace muy peligroso.
Porque tienes que tener
un modelo mental
muy diferente
a cómo funciona realmente
JavaScript.
Es totalmente alejado
a lo que busca React.
React,
una cosa buena que tiene,
en mi opinión,
que otra cosa es que sea buena
para el rendimiento,
pero buena para los desarrolladores,
es que su modelo mental
realmente es cómo funciona JavaScript.
En el que cada vez
que se renderiza el componente
es como que se ejecuta la función.
En Solid.js no pasa esto.
¿Vale?
Y esto puede costar muchos errores.
Porque ya os digo,
esto de la línea 10,
esto es incorrecto.
Esto no se puede hacer.
¿Qué significa?
Claro,
entonces constantemente
tendrías que hacer
este tipo de cosas.
GetCounter,
GetCounter,
GetCounter.
¿Qué se puede hacer?
A ver,
no soy todavía
un gran experto
en Solid.js,
pero hay formas
de poder hacer esto.
Aparte de tener
el CreateSignal,
tiene más,
le llaman como primitivos,
¿no?
Más métodos primitivos
como CreateSignal,
también tiene el CreateMemo,
por ejemplo.
Y tiene el CreateEffect,
¿vale?
Entonces,
con el CreateMemo
lo que podrías hacer
básicamente sería algo muy parecido.
Voy a poner por aquí esto.
Vamos a poner Docs.
Vamos a buscar el CreateMemo.
¿Vale?
¿Qué podríamos hacer
con el CreateMemo?
A ver,
en el CreateMemo
lo que podrías hacer
sería,
bueno, no,
porque veo que
también es un...
Estoy mirando
a ver si se puede
guardar
justamente
en una variable.
Y ya está.
Bueno,
mira,
vamos a revisar
la reactividad básica.
Una es el CreateSignal,
que este ya lo hemos visto,
¿vale?
Es exactamente
muy parecido
al UseState,
solo que tiene
las diferencias estas
que hemos visto
de que hay que tener cuidado.
¿Vale?
Entonces,
el CreateSignal
es muy parecido
al UseState,
solo que hay que tener en cuenta
que el primer elemento
es una función,
¿vale?
Y para leer el valor
hay que hacer esto.
Me gustaría
el CreateEffect.
El CreateEffect
es parecido al UseEffect,
pero no es exactamente
lo mismo.
La idea
un poquito
del CreateEffect
es depender
de alguna cosa,
por ejemplo,
que cambie
una de estos signals
y tú pues hagas
una cosa,
pero no es tanto
para que añadas
hagas un fetch
de una API
o para que cambies
el estado,
porque sería
de otra forma,
¿no?
Lo que quieres es
a lo mejor
hacer un tracking
cada vez que cambia
algún tipo de dependencia
que además
la puede detectar
automáticamente,
por ejemplo,
aquí podemos ver
que crea un efecto,
que esto ejecuta
este método
de hacer un SideEffect
con el método A
y automáticamente
detecta
que necesita
el método A,
¿vale?
no necesita
ninguna otra cosa,
no necesita
de ninguna forma
que tú le digas
que necesitas
esa dependencia,
esto es una mejora
respecto a React
que sí que necesitas
hacerlo,
¿vale?
Luego,
otra cosa
que puedes hacer
en el CreateEffect
es tener
el valor previo
que has devuelto,
o sea,
cada vez que haces
un efecto,
esto lo podríamos mirar,
que esto es bastante fácil.
Tú podrías hacer
aquí un CreateEffect,
¿vale?
tendríamos
el valor previo
del efecto
y esto puede ser útil,
a ver,
cuando haces
este returnSum,
en realidad
este return
no lo vas a ver
dentro de tu función
ni nada,
pero lo que sí que podrías hacer
por ejemplo
es un console.log
del zoom.
Imagina que quieres
un contador
que esté sumando
el valor,
el valor previo
con el valor actual,
por ejemplo,
¿no?
Lo que podemos hacer,
el cero sería
el valor inicial
en el que va a empezar
y lo que vamos a hacer aquí
es que vamos a tener
el valor previo
más el getCounter,
¿vale?
y aquí vamos a tener
la suma
de esos dos valores,
vamos a hacer un console.log
de esta suma
para mostrarla,
pero esto la idea
sería más
para hacer un tracking
o incluso podría ser
para recuperar
algún tipo de recurso,
pero ya veremos
que tiene un primitivo,
un método auxiliar
que te ayuda con esto,
muy parecido a React Query.
Y luego,
al devolverlo,
hacer un returnSum,
lo que haces
es que
lo que devuelves aquí
se va
a
pasar
como parámetro
la próxima vez
que se ejecute
el efecto
en el createEffect.
Aquí en prep
tendrás otra vez
el returnSum,
¿vale?
Así que mira,
vamos a poner aquí
que me devuelva
el prep
y el zoom,
¿vale?
Hemos importado
ya el createEffect,
vamos a ver
esto como es
y vamos a darle aquí
increment,
¿vale?
Aquí podemos ver
que está
5
zoom,
el previo fue 5
y ahora la suma es 11
porque es 6 más 5,
¿no?
Voy a poner también
el contador
actual counter
para que lo veas claro,
¿vale?
Counter,
así.
Teníamos,
ay,
espérate,
que es que no lo veis
porque esto está muy abajo,
¿no?
Me imagino,
me imagino que no lo veis
por mi cara,
¿vale?
Pero bueno,
ahora le voy a dar
unas cuantas veces
para que lo veamos,
¿vale?
Y ahora os explico
un poco el console.log,
no sé si lo voy a mover aquí,
¿vale?
Pues aquí lo tendríamos,
¿no?
Estos son los efectos,
este createEffect
que hemos puesto aquí,
pues cada vez que nosotros,
cada vez que se ejecuta
el getCounter,
que se actualiza,
fíjate que yo no tengo
aquí ninguna dependencia,
sino que este método
de forma totalmente automática,
de forma reactiva,
detecta que se ha ejecutado
este getCounter,
se ha actualizado
y vuelve a ejecutar el efecto
y así todo el rato.
Y lo que hace es que
en el previous
tiene el valor anterior
que hemos actualizado,
hemos devuelto aquí,
en el return zoom,
¿vale?
Entonces tendríamos esto
y ya el actual counter,
5, 6, 7, 8, 9, 10,
¿vale?
Y así estaríamos creando
el efecto.
Esto es para efectos,
pero ya veréis
que por ejemplo,
normalmente en React
tendríamos que crear
un efecto
siempre que queramos
actualizar el estado,
¿verdad?
o es en un click,
o sea,
o es en un evento,
un handle click
o algo así,
o es en un efecto.
¿Por qué?
Porque como en React
el cuerpo de la función
se ejecuta cada vez
que se actualiza el estado,
¿cierto?
¿Qué significa esto?
Significa
que tendríamos
un loop infinito.
Entonces,
por eso en React
tenemos que utilizar
un useEffect
para actualizar el estado.
Pero este no es el caso aquí.
Porque como os he dicho,
en Signal
este cuerpo
solo se ejecuta una vez.
¿Qué significa?
Mira,
voy a comentar esto.
Pero para que lo veas clarísimo,
aquí podríamos hacer esto,
setCounter,
¿vale?
Y le voy a poner
que esto sea
counter más uno.
Y aquí voy a recuperar
el counter
con el getCounter,
¿vale?
Y poner counter más uno,
¿vale?
Voy a guardar los cambios.
Y fíjate
que no ha pasado nada.
Que funciona perfectamente.
Esto en React
no funcionaría.
Tú hacer esto en React
no funcionaría.
¿Por qué?
Porque en React
se volvería a ejecutar
el cuerpo de la función.
Aquí no.
Es que aquí
hay que tener en cuenta
que el cuerpo de la función
solo se ejecuta una vez.
Entonces,
tú puedes poner
un setCounter aquí.
Para que lo veas
todavía más claro,
podríamos poner
un setInterval.
¿Vale?
Vamos a poner
un setInterval.
Y aquí
vamos a poner
que cada segundo
haga un setCounter
getCounter más uno.
¿Vale?
Y ahora fíjate.
Se actualiza automáticamente.
No hace falta
que utilices
un useEffect.
Porque esto,
justamente este setInterval,
pues solo se ejecuta una vez.
Entonces,
es mucho más fácil
en este caso
utilizarlo.
En este caso
en concreto,
la reactividad
es algo
que yo creo
que hace
mucho más sencillo
utilizarlo.
Porque puedes poner
aquí justamente
en el campo,
o sea,
en el cuerpo
un setInterval
y ya está.
Ahora bien,
¿cómo puedes?
Imagínate que este componente
deja de utilizarse.
Este componente,
pues imagínate
que desaparece.
Entonces,
¿cómo hacemos
justamente para
hacer que esto
desaparezca?
Porque este es un evento,
este intervalo
es un evento
que si lo dejas ahí,
pues se podría
reventar.
O sea,
se quita este componente,
se deja ese intervalo ahí,
intenta ejecutar este método,
no existe,
pues liada.
¿Vale?
Pues lo que puedes utilizar
es un método
que se llama
onCleanUp,
¿vale?
Que sería
onCleanUp.
Lo importamos
de SolidJS
y aquí lo que podemos hacer
es que cuando lo vayas a...
onCleanUp
es cuando el componente
se vaya a desaparecer,
pues vamos a tener
aquí el interval
y vamos a hacer
un clearInterval
de interval.
¿Vale?
Y con esto
ya tendríamos justamente
el hecho
de que se limpiase
el componente,
el intervalo.
Esto está,
esto está bien
porque queda mucho más fácil,
¿no?
Queda como mucho más limpio
en lugar de tener
que tener un efecto.
Esto lo puedes utilizar
para un montón de cosas.
Por ejemplo,
pues podrías hacer,
podríamos hacer
un fetch directamente
de alguna cosa
aquí en el cuerpo
de la función
y actualizar el estado
y ya está.
O sea que eso
quedaría bastante bien
y lo haría
mucho más sencillo.
Esto con el create,
con los efectos,
¿vale?
Hemos visto los efectos,
a ver si me he dejado
por algún sitio,
bueno,
por aquí parece que...
¿vale?
Hemos visto el efecto,
que el efecto ya veis
que es bastante diferente
al useEffect,
o sea que tened cuidado,
no es exactamente
para hacer el useEffect,
hay que separarlo mejor,
¿vale?
No hay que utilizar el useEffect
para muchas de las cosas.
Luego tendríamos
el createMemo,
que el createMemo
al final lo que hace,
este es muy parecido
al useMemo de React
y lo que tú tienes
es que evitas recalcular
alguna cosa
a no ser que cambien
justamente los valores,
alguna dependencia de dentro,
¿no?
En este caso,
pues creamos un getValue
de createMemo,
le pasas una función,
esto sería la ejecución
de este método,
pasándole tanto la A
como la B,
¿no?
Dos métodos.
Si cambia uno
de estos dos métodos
o la función
computeExexpensiveValue,
pues entonces tendrías
un nuevo valor aquí
en el getValue
y solo se ejecutaría
esto de aquí dentro,
¿vale?
En lugar de ejecutarse
toda la función,
todo el tal,
pues solo se ejecutaría
esa parte de ahí,
¿vale?
Es muy parecido
esto al useMemo,
solo que hay que tener en cuenta
que, por ejemplo,
es que es muy tricky,
¿eh?
Porque con estas cosillas
es un poco tricky.
Tú con el createMemo
pongamos que,
pongamos aquí
get,
¿cómo podemos hacer?
Vale,
vamos a hacer aquí
el pow,
por ejemplo,
¿no?
Que le pasas un número
y esto te hace
n por n,
¿vale?
Esto es para hacer
la potencia
de n elevado a la n.
Entonces,
lo que podemos hacer
es el getPow
y aquí lo que podemos hacer
es el createMemo,
le pasamos
en el pow,
le vamos a pasar
el getCounter.
¿Vale?
De esta forma
lo que haría este getPow
porque fíjate que a ti
te devolvería otra vez
la función
o incluso
este Spark
que hemos hecho aquí
también lo podríamos sacar.
Tenemos aquí
get,
getText,
por ejemplo,
¿no?
CreateMemo,
¿vale?
Lo teníamos así
y ya tenemos
el getText.
¿Qué es lo interesante
de esto?
Lo interesante de esto
es que en realidad
no tenemos que decirle
qué dependencias
tienen que mirar,
sino que directamente
ya las tiene en cuenta
y de forma automática
pues se va a actualizar,
¿no?
Aquí tenemos el getPow,
vamos a ponerlo aquí debajo también,
getPow
y vamos a volver
a nuestro SolidYes.
¿Vale?
Le doy a increment
y ya lo tenemos.
O sea,
lo que estamos haciendo aquí
es que cada vez
él detecta
el getCounter este,
esta ejecución
ha cambiado.
¿Vale?
Pues lo que voy a hacer
es ejecutar esto de aquí
y cambiar
en aquellos sitios
donde se está utilizando
este método,
que es aquí,
voy a cambiar justamente
lo que ha renderizado.
Eso es lo que está haciendo.
¿Vale?
¿Cuál es el problema
de todo esto?
¿Cuál es el problema
de todo esto?
De nuevo,
el problema
es que tienes que llamar
a los métodos,
¿vale?
No vale de nuevo,
es que sé que es una tontería,
pero es que si yo hago esto,
getCounter,
¿no?
Que esto es una cosa
que se hacen constantemente.
Pues esto no funciona.
Si yo ahora
todos estos getCounters
los cambio,
este lo voy a dejar,
¿vale?
Para que veamos,
pero esto es del useMemo.
Vamos a dejar este
y este,
¿vale?
Si ahora hacemos esto,
fíjate que lo he roto.
Ahora sí que me cambia aquí
el contador
porque tengo aquí
el getCounter,
pero tanto el getText,
este,
como el getPow
que tengo aquí,
eso nos cambia.
Todo se basa
en que llames
a las funciones.
Es súper importante
esta diferencia,
¿vale?
es un cambio mental
muy importante,
¿vale?
No puedes dejar
de llamar
al getCounter
porque esa
es la clave
de todo.
Creo que en Solid,
en la propia web
de Solid.js,
lo podemos mirar,
creo que hay una explicación
bastante interesante
de cómo funciona esto.
A ver,
reactive utilities,
no.
Es que
luego vais a ver
porque es que
esto es solo el principio,
tiene un montón
de historias.
Mira,
5.js
donde Solid.js
no es lo mejor.
Me gusta,
me gusta.
Reactivity,
vale,
creo que aquí,
creo que aquí,
creo que por aquí
lo hice.
Vale,
reactividad.
Claro,
aquí habla,
¿no?
De introduciendo
los primitivos,
crear un efecto,
bla, bla,
claro,
esta,
mira,
esta es otra,
que esta es otra,
¿no?
Que si quieres hacer
que lo,
es que tienes que llamar
todo el rato,
tienes que llamar
a las funciones.
Mira,
aquí te explica un poco
cómo funciona,
¿no?
Que los signals son,
al final,
esto funciona con eventos,
o sea,
lo que está haciendo
es emitir un evento.
Tú cuando llamas
al setCounter,
cuando este setCounter
es ejecutado
en esta línea de aquí,
lo que está haciendo
de alguna forma
es emitir un evento
y el evento es,
eh,
he actualizado el estado,
¿vale?
Por lo tanto,
lo que haces con el getCounter,
todos los getCounter
que tenemos en nuestro código,
en realidad es como si fuese
un evento de escucha,
¿no?
Estoy escuchando
el evento
de cuando se actualice
el estado,
de forma que
lo que vemos aquí,
este getCounter
se va a cambiar
por el valor,
¿vale?
En todos esos sitios
donde esté
este método de getCounter
se cambiará
por el valor,
se volverá a ejecutar
automáticamente
y se cambiará
por el valor.
Aquí podríamos tener
un poquito
una implementación,
yo creo que esto
es pseudo código,
¿vale?
Esta no es la implementación
tal cual,
donde tienes
todos los suscriptores,
o sea,
tú haces un createSignal,
le pasas el valor inicial,
este createSignal
sería este que tenemos aquí,
¿vale?
Con el valor inicial
y lo que hace aquí
es crear un set,
bueno,
pensad que es como un array,
pero bueno,
un set es un poquito
más especial,
donde está guardando
todos los suscriptores,
¿no?
Tiene dos métodos,
que uno es el de leer
y otro es el de escribir,
que estos son los dos
que devuelven,
¿ves?
Que hace return
y son dos elementos,
leer y escribir,
que es exactamente
lo mismo que tenemos aquí,
¿vale?
Con el getCounter y setCounter.
Entonces,
el de leer,
dice, vale,
constListener,
getCurrentListener.
Muy bien,
pues esto lo que devuelve
es el listener
y una vez que tiene el listener,
lo añade en esta lista
de suscriptores que tiene
y devuelve el valor.
Al leerlo,
lo que hace es devolver el valor
y ya está.
Como tiene
el que está escuchando,
cada vez que cambie el valor,
como ya lo tiene aquí añadido,
pues cuando cambie el valor
aquí en el write,
fíjate,
lo que hace es iterar
todos los suscriptores
y lo que hace es
como decir,
vale,
suscripción,
tienes que funcionar
porque tienes un nuevo valor,
¿vale?
Y entonces devuelve el nuevo valor.
Es muy loco,
¿vale?
Te puede follar la mente un poco,
te puede fastidiar bastante la mente,
pero así es.
Y si el getCounter
lo pasas como una función
al counter,
y si el getCounter
lo pasas como una función
al counter,
no sé a qué te refieres
al pasarlo con una función
al counter,
¿qué counter?
Pero bueno,
ahí está.
Lo bueno del set
es que no repite valores,
entonces no podemos tener
el mismo subscriber.
Efectivamente.
Vale.
Pues entonces,
el tema
que tiene su cosa,
¿vale?
Esto es,
esto es un poco
solo el principio,
¿vale?
Ah,
de quitarle los paréntesis,
o sea,
claro,
podéis quitar los paréntesis
y como esto es una función,
pues se ejecutará,
lo que pasa es que yo no lo recomiendo,
¿vale?
O sea,
os recomiendo mucho
que dejéis los paréntesis
por un millón de historias,
¿vale?
Lo primero es porque,
fíjate que hasta cambia
el highlighting.
Tiene mucho de RxJS,
tiene un montón de historias,
¿eh?
Si haces counter igual,
setCounter dos veces,
ya madreval,
no entiendo lo que quieres decir.
¿Hay necesario ejecutar el counter?
Que siempre es necesario
que ejecutéis el getCounter,
¿eh?
O sea,
que tenéis que hacer el getCounter y tal.
Sí,
mira,
mentalmente se parece más a Vue.js
que a React,
¿vale?
Pero,
o sea,
como que al escribirlo
se parece más a React.js,
pero tiene cosas de reactividad
que se parecen más a Vue.js.
Es bastante curiosa la cosa.
Fringer,
Gamer acaba de entrar
y no entiende nada.
Bueno,
es programación
y lo que estamos,
de lo que estamos hablando
es de una nueva biblioteca
que es como
una alternativa a React.
se parece mucho a React,
pero cambia totalmente
la reactividad.
Muchos de los problemas
que podéis encontrar con esto,
de hecho,
vamos a verlo,
¿vale?
Vamos a hacer algo.
Vamos a complicar un poquito
nuestro componente
de contador
porque vais a ver
algunos problemas
que nos podemos encontrar.
Bueno,
ahora me he cargado
alguna cosa por aquí,
pero vamos a arreglarlo.
¿Vale?
Vamos a dejar el getCounter
y todo esto.
Voy a dejar este
CreateEffect.
¿Vale?
Ahora mismo funciona
todo perfectamente,
¿no?
Genial.
Vamos a hacer una cosa.
Vamos a crear otro componente
que le voy a llamar Counter.
Y este Counter
lo que recibe
son unas props.
Vamos a...
Vamos...
Lo que vamos a hacer
es renderizar todo esto,
pero de una forma
un poco distinta,
¿no?
Porque esto,
como llega por props,
lo que vamos a tener...
¿Vale?
Esto por aquí.
Vamos a hacer una cosa.
Este le llega por props,
el counter.
El text le llega por props también.
El pow le llega por props.
Y aquí lo que vamos a hacer
este setCounter,
getCounter y tal,
lo que podemos hacer
en lugar del getCounter
y todo esto,
pues sería básicamente
llamar a la función increment,
¿no?
O sea que llamamos
a la función increment
que también le va a llegar
por props.
¿Vale?
Bueno.
Ahora vamos a quitar
todo esto.
Vamos a utilizar counter
y vamos a empezar
a pasarle el counter.
Vamos a...
Ya sabemos que tiene que ser
llamando a la función,
pues eso lo vamos a hacer bien.
Ya hemos aprendido la lección,
¿no?
El getText,
ya hemos aprendido...
Ahí el text
tiene que ser con el getText,
¿vale?
El pow tiene que ser el getPow.
Nos faltaría el increment,
¿no?
El increment
vamos a intentar
que sea así,
setCounter
y que esto, pues sea getCounter
más uno.
Y este increment
se lo pasamos como prop
y le pasamos aquí increment,
¿vale?
Vamos ahora...
Voy a poner esto así.
Y esto,
vale, parece que hay algún problema
porque el counter
is not defined.
Vale,
counter is not defined
porque está aquí en las props.
Vale,
perfecto.
Lo que justamente quería
era llegar a este punto,
¿vale?
Venga,
¿qué es lo que tenemos
que hacer aquí?
En el counter
me gustaría extraer
las props, ¿no?
Vamos a extraer
tanto increment
como counter
como text
y pow.
Esto es lo que harías
en cualquier función
y en React, ¿no?
Voy a guardar los cambios
y parece que funciona bien.
Le voy a dar a increment
y no funciona.
¿Por qué no funciona?
¿Qué pasa?
¿Sabes?
O sea,
no funciona.
Nos acabamos de cargar
ya nuestro pequeño componente.
¿Dónde está el problema?
¿Dónde?
¿Qué es lo que ha pasado aquí?
¿Qué ha pachado?
Puedo ver que aquí
el constructor del componente
se ejecuta una vez.
A ver,
esto parece que funciona.
Si aquí pongo un console.log
y pongo el counter,
¿vale?
Puedo ver que aquí
sí que el counter
sí que parece ser
que el cuerpo funciona,
pero yo cada vez
que cambio incremento
no se están reflejando
en la UI los cambios.
Lo que está pasando
es que no puedes hacer
una deconstrucción,
no puedes desestructurar
las props.
Tendríamos que dejar
las props
y aquí
tenemos que poner
props.counter,
props.text,
props.pou,
props.increment.
Y ahora,
ahora sí que funciona.
Claro,
es que,
es que,
es que,
¿qué pasa con esto?
Claro,
para poder ser reactivo
no puedes
quedarte con los primitivos
porque los primitivos,
claro,
no tienes una forma
de engancharte
a estos primitivos
una vez que tú
desestructuras el objeto.
Esto es una de las razones
por las que a mí personalmente
no me gusta,
no me gusta Sol.yes,
tiene demasiada magia
en la que tienes que pensar
que al final,
obviamente,
tendrías que utilizar
un linter
porque si no,
estos errores
los vas a tener
constantemente.
Lo que está pasando aquí
es que,
digamos que las props
sería un objeto proxy,
o sea,
sería un proxy
en la que detecta
que cada vez
que tú haces un getter,
props.counter,
lo detecta
de forma que crea
este vínculo
de cada vez
que este getCounter
lo crea
con este props.counter.
Tú haces aquí
un getter
que sería
intentar acceder
a la propiedad
de un objeto
con ese getter
dices,
vale,
ahora que tengo esto
lo voy a enganchar
al getCounter,
¿vale?
Lo que está ocurriendo aquí
es que este props.counter
lo engancha
con este getCounter.
Claro,
si tú,
esta duele,
esta duele,
sí,
esta duela.
Aquí,
lo malo
es que aquí
ya tienes que pensar
fuera de JavaScript,
¿sabes?
Porque en JavaScript
esto te funcionaría.
Claro,
esto es lo bueno
que tiene React
y lo malo
que tiene Solid.js.
Que tienes que pensar
un poco
en cómo funciona
Solid.js por detrás,
¿no?
Toda la magia
está haciendo.
¿Cuál es el,
aquí,
cosas que se pueden hacer,
¿no?
Porque veo que muchos
me estáis preguntando,
Moni,
¿qué se puede hacer
con esto?
Bueno,
lo que estoy haciendo,
lo que estoy haciendo
es lo que se tendría
que hacer.
Otra forma,
si no recuerdo mal,
en la documentación
había por aquí,
a ver,
docs,
¿vale?
Docs,
se ha quedado pensada
las docs de Solid.
Reactive Utilities,
es que no hay,
es que tienes
para hacer
Merge Props
y Split Props,
¿vale?
¿Qué pasa?
No puedes,
con las props
no puedes utilizar
ni la estructuración,
no puedes utilizar
tampoco,
no puedes mezclar,
o sea,
por ejemplo,
no puede,
no podría añadir props,
o sea,
no podría hacer aquí
Object
y decir props
y luego aquí
poner name,
hola,
¿vale?
Esto tampoco funcionaría
porque esto lo rompería
también.
Para esto,
para este tipo de cosas
hay que utilizar
justamente
este método
Merge Props
y para hacer
un Split
de las props,
por ejemplo,
para sacar una prop
habría que hacer
este Split Props,
¿vale?
Es un rollo,
es un rollo.
Hay que hacer
este Split Props
para separar props
y siempre
hay que utilizar
el acceso,
como podéis ver aquí,
local.children,
o sea,
props.children.
Siempre hay que utilizar
justamente
el props
y no puedes sacarlos.
Es lo que os comento,
que un gran poder
conlleva una gran responsabilidad.
Este es un problema
que hay,
¿vale?
O sea,
tiene cosas que parecen
más sencillas que React
pero de repente
hay otras
que no son nada fáciles
de entender
y que justamente rompe
cómo utilizarías
JavaScript
en tu día a día
y eso puede
ser un poco problemático,
¿vale?
Es como que,
vale,
tienes mucho rendimiento
a cambio de una experiencia
de desarrollo
que, bueno,
si te la sabes de memoria,
si tienes un linter
que te lo chiva todo,
pues igual no tienes ningún problema,
pero bueno,
hay que tenerlo en cuenta.
Esto sería otro problema,
¿no?
Ya hemos visto
cómo lo tendríamos
que solucionar
utilizando siempre props.
Las props
no se pueden
destructurar,
siempre hay que utilizar
props.counter,
no se puede utilizar
ni el rest operator
ni el spread,
¿vale?
Así que tenedlo en cuenta,
esta será la gran diferencia
y esta es la diferencia básica,
¿vale?
Con que tengáis en cuenta
que Signal
es como muy parecido
a un clon,
es un clon de React,
o sea,
es obvio,
no creo que a nadie
le sorprenda
que es un clon de React.
La única diferencia,
bueno,
pues que tiene
la reactividad
es totalmente,
se entiende
de forma totalmente distinta.
Tienes aquí
unos ciclos de vida,
el on mount,
el on clean up
y on error,
el on clean up
lo hemos visto antes
con el set interval,
el on mount,
esto se ejecuta
solo una vez
porque ya hemos visto
que no tenemos efectos
en los componentes de React,
entonces el on mount
sería un método
que tú puedes poner
para que veas
cuando se ha ejecutado
por primera vez,
por ejemplo,
on mount,
y aquí pondrías
componente
se ha
montado,
¿vale?
Y esto se ejecutaría
una sola vez,
esto puede ser útil
para tracking,
para cosas así.
¿Qué más?
Luego tenías
el on clean up
que esto es cuando
se destruye
el componente
y el on error,
¿vale?
Que esto es cuando
ha ocurrido algún tipo
de error.
Aquí tenemos
un montón de utilidades
reactivas
que, claro,
necesitas un montón
de helpers,
obviamente, ¿no?
Uno de ellos
es lo de create effect
y todo esto,
lo de mergear
las props,
split de las props,
esto sería como
para fusionar
dos objetos,
claro,
no puedes hacerlo,
este merge props,
no lo puedes hacer
tal cual.
De hecho,
claro,
¿qué problema
te puedes encontrar
aquí?
Que no puedes utilizar
tampoco valores
por defecto,
¿vale?
Aquí,
como esto no se puede
utilizar aquí,
tú aquí no puedes
sacar el counter,
o sea,
yo aquí no puedo
sacar el counter
y hacer rest of props,
esto no funciona.
Entonces,
tú no puedes poner
que este counter
sea cero,
¿vale?
No puedes hacer esto,
no puedes ponerle
el valor inicial
que sea cero,
esto no funciona,
no puedes tener
default props.
Para hacer las
default props
en solid.js
lo que tendrías
que hacer
sería algo
totalmente distinto,
como esto,
¿vale?
Tendríamos que
poner esto,
¿no?
Tendríamos aquí
las props
from params
y aquí tendríamos
props,
mergearíamos,
¿no?
Y tendríamos el
counter,
pues que esto sea
cero
y esto lo
mergearíamos
de las props
from params,
de forma que
si no me pasa
en el counter,
¿vale?
Y aquí pongo
que esto es 10,
pues estas props
sí,
ahora sí que funcionarían.
Vamos a ver
que se está quejando.
Ah,
que he puesto
el on mount
por aquí
para el ejemplo.
On mount
y a ver
qué más.
Merge props
no define
también
porque
es que esto
no tiene el linter,
¿vale?
Pero fíjate,
este contador
no se actualiza,
es normal
porque lo he quitado
de aquí,
¿vale?
Aquí el counter
get counter
lo he quitado
porque quería enseñarte
cómo se puede hacer
un valor inicial
que he puesto
counter 10.
Es la única forma
que tienes
de ponerle
un valor inicial
a la prop.
Tendrías que hacer
este merge props,
¿vale?
O sea,
tenlo en cuenta también.
Es un cambio
brutalísimo,
brutalísimo.
En este caso
a mí me parece
un cambio
que pierde mucho
respecto a React,
¿no?
El hecho de no poder
tener valores
por defecto
de una forma fácil
y que tengas que utilizar
el merge props
se hace más difícil
de leer,
¿no?
Ya hemos visto
que algunas cosas
tienen ventajas,
otras
tienen desventajas,
¿no?
Por ejemplo,
los efectos
los puedes poner
en el cuerpo
de la función,
el cuerpo
de la función
solo se ejecutan
a vez,
eso parece súper fácil.
¿Desventajas?
Pues estas cosas
las estamos viendo,
¿no?
Las props
no las puedes
destructurar,
no puedes poner
valores por defecto,
si tienes que utilizar
este merge props
que es un método
de la librería.
Bueno,
cositas buenas,
cositas malas,
¿no?
Ya hemos visto
cómo se hacen
en cada una
las cosas
diferentes,
¿vale?
Vamos a seguir,
vamos a intentar
hacer,
si os parece,
una llamada
a una API
para que veáis
un poco
cómo se haría.
Voy a poner aquí
este
Rick and Morty
API,
vamos a intentar
hacer una llamada
a una API,
no lo he hecho nunca,
o sea que
vamos a tener que ver
la documentación,
obviamente.
Vamos a utilizar
la de REST
para no liarnos,
API character,
voy a ir un poco
a saco,
o sea voy a
voy a recuperar
un usuario,
ah bueno,
vale,
así con API character
ya me devuelvo
unos cuantos,
vale,
pues vamos a utilizar
el de API character,
vamos a ver si lo conseguimos
y luego os enseñaré
unos componentes
especiales
que tiene
Solid 10
justamente para manejar
listas
y para manejar
también renderizados
condicionales,
que es bastante interesante,
pero también
es un poco raro.
Entonces,
vamos a
vamos a
quitar todo esto,
esto me lo voy a cargar,
voy a dejarlo por ahí
al final,
el counter,
esta app
me la voy a cargar,
la voy a dejar también
por el final,
más que nada
para que esté
por ahí,
por un tema,
vale,
esta me la cargo
y vamos a volver
a crear
desde cero
pues un
una aplicación,
vale,
voy a dejar
esta documentación
me la pongo
por aquí
y aquí
nueva app
y guardo,
vale,
nueva app,
empezamos de cero
en un momentito,
venga,
¿qué es lo que
lo que tiene
SolidJS
para crear
recursos?
Una cosa
que me gustaría probar
porque ni siquiera
sé si se puede
pero creo que sí
que se debería
sería
getResults,
setResults,
createSignal
y aquí
podríamos crear
no sé si es un objeto
un array
o deberíamos crear
a ver cómo es la API
de Rick and Morty
de characters
es un objeto,
vale,
pero podemos guardar
los resultados,
vale,
entiendo
que
no sé si esto es posible
pero teniendo en cuenta
cómo es
SolidJS
deberíamos poder ser capaces
de hacer algo así
porque ya hemos dicho
que el cuerpo de la función
solo se ejecuta una vez,
¿no?
entonces tendríamos la respuesta,
esta no sería la forma correcta
de hacerlo en SolidJS
porque ya veréis que luego
se hace de otra forma
pero quiero probar esto
para ver si entiendo exactamente
que realmente esto se puede
hacer,
¿vale?
entonces
esto sería de una forma,
¿no?
y una vez
voy a ver que aquí
tengamos los resultados
para poder hacer esto
tenemos que hacer
un console.log
del getResults,
¿vale?
vale,
no me ha dado resultados
getResults
setResults
response.results
será que a lo mejor
a ver
response.results
vale,
aquí es que lo tiene
sí que me está devolviendo
o sea,
sí que está haciendo la llamada
¿vale?
aquí la podemos ver
que me está haciendo la llamada
pero dentro del console.log
no está haciendo el getResults este
vamos a hacer una cosa
vamos a hacer un
getResults
getResults
createMemo
vale
getResults
createMemo
al final
es lo mismo
o sea,
es que no me lo está haciendo
porque a lo mejor
un console.log
no lo está haciendo
pero aquí
deberíamos ser capaces
de hacer
getResults
.map
Result
Result
H1
Result
Return
espérate
expected
porque este getResults
no le gusta
que haga esto
porque esto es un fragment
vale
ahora esto
vale
vale
h1
result
y por ejemplo
pues que me ponga la idea
de cada uno
a ver si esto funciona
vale
esto funciona
vamos a poner el nombre
mejor
vale
vale
pues ya tendríamos aquí
básicamente el resultado
de la API
vamos a poner un poquito más
vamos a poner el nombre
no sé si se le puede poner
una imagen
es sol.image
y esto tendría que ser
vamos a ponerle un dip
vale
bueno
anda yo también
la imagen
la he puesto
como si se renderizase así
la imagen
anda que yo también
vale
esto así
result image
y tal
vale
ya tenemos ahí
las imágenes
perfecto
más o menos
lo importante es que tenemos resultados
que vienen de la API
y tal
o sea estamos viendo
que podemos hacer
el
voy a quitarlo de nueva app
vale
vamos a dejar esto así
ya vemos
que podemos hacer el fetch
en el cuerpo de la función
¿por qué podemos hacer esto?
porque el cuerpo de la función
solo se ejecuta una vez
a diferencia de RIA
que se ejecutaría cada vez
que actualizamos el estado
vale
super importante
entonces
tenemos aquí
cada uno de los elementos
de la API
lo hacemos así
y ya estaría
ahora bien
justamente
en Solid.js
hay una documentación
o un método
digamos
que es muy parecido
a React Query
que es
create resource
creo que es
oh resource
espérate
base reactivity
create resource
ah pues lo había buscado
bien
vale
fíjate
lo que haces aquí
es create resource
le pones el get query
y tienes el fetch data
get query
lo que se supone aquí
que creas
una señal
que se puede manejar
administrar
con peticiones
asíncronas
vale
el fetcher
es una función asíncrona
que acepta
un valor de retorno
que es
la fuente
que si se provee
y devuelve una promesa
que se resuelve
con el recurso
y entonces
se hace el set
o sea
cambia como el estado
o la señal
vale
el fetcher
no es reactivo
o sea
que para utilizar
la
utilizar el primer argumento
es opcional
por si lo quieres utilizar
más de una vez
o sea
este get query
es opcional
lo que significa
es que cada vez
que el get query
entiendo que cada vez
que el get query
cambie
entonces ejecutaría
el fetch data
y entonces cambiaría todo
esto es lo que haría
que cada vez que hagas
el get query
que cambie
harías ejecutar
el fetch data
pero en nuestro caso
no podemos hacerlo
si la fuente
resuelve
a false
null
o undefined
no va a hacer
el fetch
vale
la fuente
sería este
el source
sería esto
si esto devuelve
false
null
o undefined
entonces no volvería
a hacer un fetch data
esto puede ser interesante
porque hay veces
que no nos interesaría
que vuelva a hacer
un fetch del data
entonces aquí tendríamos
un poquito
const data
esto nos devuelve
un mutate
y un refetch
el data
de nuevo
es una función
vale
no tendría los datos
sino que sería una función
y lo bueno
es que tendríamos
una función
para leer el dato
pero también tendríamos
una forma de ver
si está cargando
si hay un error
podríamos mutar
directamente el valor
sin necesidad
de crear una promesa
esto sería
como para
si queremos hacer
optimistic value
esto para hacer
UI optimista
imagínate que tienes
un formulario
y que
o imagínate
darle al botón like
de facebook
lo que tú puedes hacer
es crear un recurso
de que cuando
cambie
el estado
de algo
pues que haga el botón like
que haga la petición
pero visualmente
mutas
ya el valor
para que sea true
por ejemplo
y así visualmente
el usuario lo ve
pero todavía no ha terminado
la forma asíncrona
vale
esto sería para hacer
una UI optimista
y esto
un refetch
que sería para
la request
use because
bueno
por si se quiere hacer
un refetch
y ya está
en este caso
una cosa que
no sé si
tendríamos que hacer
un refetch
no sería de primeras
bueno
vamos a ver
cómo funciona
no tiene sentido
data y data loading
a la vez
no tiene sentido
no tiene sentido
pero porque no se suelen
no entiendo que nos utilizarían juntas
vale
vamos a ver si somos capaces
de crear nuestra primera request
nuestro primer fetch
vale
tenemos el query resource
voy a quitar
esto
lo vamos a poner más chiquitito
esto lo vamos a poner así
lo que tenemos que crear
primero
es el fetch data
vale
así que vamos a
quitar
esto voy a tirar para abajo
para nuestro ejemplo de antes
vale
y necesitamos un método
que es fetch data
este fetch data
yo me imagino
que es básicamente
esto que habíamos hecho aquí
esto que habíamos hecho aquí
pam
y sería devolver esto
aquí
deberíamos
poder pasarle una idea
o lo que sea
que sería lo que
le devolvería
la source
que hemos visto
el primer parámetro
pero como es opcional
yo entiendo que
no necesitamos pasarle nada
y ya está
y esto en lugar de hacer
un set de resolves
lo que hacemos directamente
es devolver
el response
punto resolves
vale
si esto hace un catch
entiendo que
o sea
no necesitamos hacer un catch
porque esto
si falla
por algún motivo
deberíamos tenerlo
en el data punto r
vale
entonces quito todo esto
y aquí en data
deberíamos tener
los datos
ahora
este data
es una función
o sea que vamos a poner
get data
y esto sea
get data
recuperar los datos
mapearlos
y ya está
hay una cosa
que me sorprende
y es no poder pasarle
un valor inicial
al query resource
fetchers
ah mira
options
initial value
vale vale
initial value
t
o sea aquí sí que
le puedes pasar
un initial value
y le podríamos pasar
que es una arribación
ya me extrañan a mí
vale
podríamos pasar esto
voy a
voy a quitar esto
lo voy a poner por aquí
y si refresco esto
vale
pues ahora está funcionando bien
a ver voy a eliminar esto
para ver que peta
sí
vale pues ya tendríamos
con esto
nuestra
nuestra API
estaría funcionando
está haciendo automáticamente
todo esto
de recuperar los datos
utilizamos este fetch data
lo pasamos aquí
creamos un recurso
esto no lo necesitamos
para nada
básicamente
se puede quedar así
pero bueno
es importante saber
que tenemos
una forma de mutar
el estado
si queremos
por ejemplo
poner esto en favorito
podemos mutar el estado
cambiar eso a favorito
mientras
hacemos la API
la llamada la API
para que cambie
justamente eso
en la base de datos
y el refresh
sería para ejecutarlo
y volver
a recuperar los datos
de hecho lo podemos hacer aquí
el refresh
y debería hacer dos veces
la llamada
pero es que lo podemos hacer
mira
esto es muy raro
poner aquí tres llamadas
que va a hacer tres refresh
pero no va a hacer
un loop infinito
de hecho hacer loops infinitos
sería bastante complejo
en Solid Yes
vale
pues ya tenemos esto
ahora te quiero enseñar
el
¿cómo se llama esto?
el forno
el switch
vale
esto sería un poco
como lo hacemos
normalmente
¿no?
o sea
como lo haríamos un poco
al react style
pero Solid Yes
tiene como diferentes
componentes
que se llaman
de control flow
mira
que están aquí
estos eran los
de control flow
que claro
como
una de las razones
por las que Solid Yes
pues tiene tan buen rendimiento
es por el tema
de la reactividad
como lo controla
como los elementos
se crean
y todo esto
el problema
de hacer un map
el problema
de hacer este map
este map
que tengo aquí
es que este map
siempre
siempre que cambie
este get data
siempre que cambie
este get data
va a crear un nuevo array
o sea
esto es imposible
que lo puedan
hackear
¿sabes?
cuando cambie esto
este map
siempre va a volver
un nuevo array
y esto
pues sería
poco performante
para Solid Yes
porque ya que puede manejar
mejor la reactividad
claro
esto haría que siempre
que cambie
el valor de get data
cree un nuevo array
imagínate que yo voy
haciendo aquí
refetch
uno tras otro
pues lo que pasa
¿no?
pues que estaría creando
todo el rato
un nuevo array
cada vez que hago un refetch
o cada vez que llamo
a la app
y me devuelven los datos
pues estaría creando
por este punto map
un nuevo array
esto es como funciona
el map del array
o sea
esto no es ningún secreto
el map
que es lo que devuelve
un nuevo array
no muta
el array original
¿verdad?
pues
entonces
tienes aquí
como diferentes componentes
que te ayudan un poco
a evitar este tipo
de problemas
¿no?
aquí por ejemplo
¿ves?
aquí podemos utilizar
un for
de each
y lo bueno
es que esto
sí que puede
evitarte
el crear un nuevo array
a lo mejor
si detecta
que los elementos
que está utilizando dentro
no tienen
o no han cambiado
entonces sí que puede
justamente
evitártelo
aquí tendríamos un fallback
que entiendo que esto es en el caso
de que
no sé por qué pone loading
pero lo podemos mirar
porque fallback
será si el array es vacío
que pone loading
me imagino
¿vale?
vale
ítem
índex
venga
vamos a probar
el for
¿vale?
básicamente
el for
habría que añadirlo aquí
también
bucle
y lo que haríamos aquí
sería
for
para cada
del get
data
que habría que ejecutarlo
el fallback
le voy a poner
si os parece
el loading este
también
¿vale?
para cada uno
tendríamos el item
y aquí lo que debíamos renderizar
es esto de aquí
para cada uno del item
esto de aquí
¿vale?
esto
todo esto
me lo podría
lo podría eliminar
el for este
que cierre por aquí
y esto
lo que tiene que cerrar esto
y luego esto
¿vale?
bueno
se ha quedado en el loading
pero esto es porque
no he puesto
no he utilizado los items
vale
pues ya lo tenemos
bueno
se ve muy rápido el loading
¿no?
pero podemos ver
que el fallback es
cuando el array
entiendo que está vacío
¿no?
hace el loading
y finalmente
cuando los tiene
pues
renderiza estos
o sea
tiene diferentes
control flows
por ejemplo
aparte de este
tiene otro
que sería el de show
así que aquí
podemos hacer show
lo importo
¿no?
cuando
y aquí ponemos
está cargando el componente
pues lo que podemos hacer
sería
por ejemplo
when show
no sé qué
pues aquí podemos poner
el loading
¿vale?
load
¿qué más?
podríamos show
when
hay un error
get data punto error
¿vale?
pues podríamos hacer
deep
error
y esto sería
para lo demás
le podríamos quitar
el fallback
porque el fallback
total
tiene más que ver
con cuando está en loading
guardo los cambios
y bueno
se ve el loading
ahí un momento
podría hacer que esto falle
a ver si
me invento un poco
mira ¿ves?
ahora sí que sale
el error
veo que sale el loading
pero me imagino
porque este data
el get data punto loading
no cambia
lo cual es un poco raro
porque debería cambiar
el valor
y ya está
¿sabes?
no debería entrar en este
para evitar que entre a los dos
también tiene otra cosa
que se puede utilizar
que sería el switch
y este además
sería un poco
con el que se utilizaría
el tema de
o sea es un switch
es exactamente un switch
y con esto se podría hacer
como un router también
o sea teníamos el switch
el fallback
sería el
por defecto
vamos a poner el
que sea el loading
¿vale?
hacemos un switch aquí
¿vale?
y ahora haríamos un match
o sea que hacemos match
cuando
ponemos
get data punto error
cuando hay un error
vale pues vamos a mostrar el error
cuando
match
when
get data
¿vale?
cuando hay datos
vale pues vamos a enseñar
vamos a poner este
por ejemplo
quitamos los shows
y hacemos esto de los match
¿vale?
bueno
mira hay un error
ah porque
digo porque hay un error
pero si
porque no he cambiado
lo de la API
a ver vamos a recuperar
la API
la tenemos por aquí
character
vamos a dejar esto así
¿vale?
y ahora no funciona bien
lo interesante de esto
es que sepas
que tiene unos componentes
de control del flow
y justamente
son útiles
por el tema este
de que
te puede
te puede
evitar
volver a renderizar componentes
que ya los tiene
o ya los
o sea
por un tema de reactividad
tú cuando haces un map
estás creando un nuevo array
con esto
te lo podrías evitar
podría ser que lo evitase
¿vale?
creo que esos son todos
bueno aparte
tienes el error boundary
eso sería muy parecido
alguien preguntaba antes
¿cómo podría hacer un router?
entonces con signal
aparte de que
crearán bibliotecas y tal
este switch
es perfecto
justamente para eso
porque fíjate
aquí podrías tener
root.net
punto
root.
joder
no se pone
path name
e igual home
¿vale?
imagínate
pues aquí podrías poner home
y aquí tendrías home
match
no sé qué
no sé cuánto
al final puedes ver
la ruta que vas teniendo
y aquí renderizarías
el componente que quisieras
y ya lo tendrías
y ya está
¿vale?
bueno
esto es una pequeña
pequeña introducción
a lo que es
solid.js
el problema
si me preguntas a mí
yo con la mano del corazón
te diría que no creo
que hay mucha gente
que está muy hipeada
con solid.js
yo sinceramente
uno
es una copia
a React
es un clon
solo que cambia totalmente
el concepto de reactividad
es interesante eso
es interesante
pero no veo que
vaya a hacerse
de repente
súper famoso
súper
o sea que vaya a desbancar React
lo veo improbable
veo
muchos problemas
a la hora de
este
cambio de mentalidad
que puede costar bastante
aunque sí que le veo
ventajas de performance
y le veo
algunas ventajas
y me gustan
algunas cosas
como los control flow
que tiene
estos componentes
para controlar
el switch
el for
el show
pues son interesantes
yo la verdad
es que creo
que
el problema
es que la experiencia
de desarrollo
puede ser un poquito
frustrante
o más verbosa
es verdad que React
pues tiene efectos
pero es que aquí
el tema este
de las props
a mí lo de las props
me parece una
una locura
y a la larga
en una aplicación
muy grande
puede convertirse
en algo
que te puede dar
demasiados problemas
a mí me parece
que es eso
no
dice
no te gustó nada
no mentira
no he dicho
que no me guste nada
le veo
cosas buenas
y cosas malas
pero hombre
os quiero decir
la verdad
no os voy a decir
perfecto
o sea
no os he dicho
cosas buenas
el rendimiento
es súper pequeño
reactivo de verdad
me gusta
lo del
bridge resource
me gustan
los componentes
del control flow
a ver
las cosas
no son blanco
o negras
me encanta
o lo odio
no
pero
creo que si vienes
de React
te puede costar
muchísimo
el hecho
de cambiar
el modelo mental
pareciéndose tanto
te puede costar mucho
que no vienes
de React
y vienes de cero
pues seguramente
si te gusta mucho
la programación funcional
porque muchas de las cosas
de reactividad
o te gusta mucho
RxJS
muchos de estos conceptos
te pueden gustar más
que a lo mejor
como lo hace Ria
que también tiene su magia
pero
a mí
una cosa que me echa
mucho para atrás
es el hecho
de que ciertas cosas
como el hecho
de no poder
destructurar un objeto
eso es bastante
una cosa que tiene buena Ria
que es que no deja de ser
JavaScript
para lo bueno
y para lo malo
en cambio aquí
estamos como generando
un subset
de cosas que podrías hacer
y que no puedes hacer
y eso es una cosa
que es una desventaja
a mi parecer
pero de nuevo
a ver
si yo lo tengo que utilizar
si yo lo tuviera que utilizar
a día de hoy
pues seguramente
sería utilizando React
porque tampoco es que me cambia la vida
utilizar
SolidJS
y la comunidad que hay detrás
es mucho más pequeña
y todo esto
pero
me parece interesante
pero es que he visto mucha gente
que decía
no esto es
va a matar a React
y tal
y hombre
creo que tampoco
tampoco nos pasemos
de hecho es que
es que es una copia
o sea
se lo ha clonado
solo que ha cambiado
un concepto
con el que no estaban de acuerdo
un poco de React
que es la reactividad
y ya está
es así
y si te gusta más
este tipo de reactividad
pues genial
pero claro
el día de mañana
te puedes perder otras cosas
que el equipo de React
pueda llevar
igual que en su día
hizo los hooks
y eso cambió
un poco
las reglas del juego
pues eso
pero bueno
espero que os haya gustado
un poquito
el tema este
¿crees que aprendiendo
la forma de trabajar
con SolidJS
te sirve para algo
en otro framework?
sí
te puede servir
dar tiles
para un poco
de Svelte
View
creo que tiene cositas así
que sí
de reactividad
que es un poquito
que sí que se parece
pues amigos y amigas
me voy a marchar
porque
hoy tengo cita
con mi pareja
que nos vamos a
con mi pareja
con mi pareja