SolidStart: La Forma de los Frameworks del Futuro

Hola, JS Nation. Espero que todos estén teniendo un evento increíble hasta ahora y disfrutando de esta increíble conferencia. Estoy aquí para contarles un poco sobre algunas cosas interesantes en las que he estado trabajando y que he estado usando y espero que también encuentren interesantes.

Bueno, si estuviéramos haciendo esta charla en persona, les haría tres preguntas. La primera sería, ¿alguna vez han usado SolidJS? La segunda, en realidad la primera sería, ¿han oído hablar de SolidJS? La segunda sería, ¿han usado SolidJS? Y la tercera sería, ¿alguna vez han visto o leído Dune? Porque de manera similar al personaje principal, Poltergeist, en el universo de Dune, Solid mostró a todos el camino hace seis años. Y este fue un camino de reactividad, un camino de reactividad de grano fino, porque esto es donde estábamos hace seis años cuando Solid salió.

Ahora, hay una diferencia entre la reactividad de grano fino, que es donde estaba Solid, y la reactividad de grano grueso. La diferencia es que, cuando tienes un sistema reactivo de grano grueso, el framework necesita ejecutar código para básicamente averiguar dónde ocurren las actualizaciones en la UI. Mientras que cuando tienes un sistema de grano fino, el framework no necesita ejecutar este código. Está impulsado por esta primitiva que se llama señales, y las señales le dicen al framework que algo cambió, y por lo tanto permiten que el framework sea más de grano fino en cierto sentido. Así que esto es donde estábamos hace seis años. Ahora, avancemos en el tiempo. Aquí es donde estamos. Como pueden ver, casi todos vieron el valor de la reactividad de grano fino y las señales, y han pivotado para introducir algún tipo de nivel, algún tipo de señales en su código y en sus frameworks.

Ahora, esto estaba sucediendo algo nuevo apareció hace un par de tres, cuatro años, y la gente comenzó a hablar sobre esta nueva cosa, que no es una cosa nueva, que ha estado alrededor por un tiempo, pero no se había hecho en el mundo de JavaScript por un tiempo, o no había estado activamente en el mundo de JavaScript por un tiempo, que es la renderización del lado del servidor. Y todos estaban pensando, está bien, sí, la renderización del lado del servidor, eso es bastante interesante, nos ahorra un montón de tiempo, podemos pivotar un montón de cosas del cliente a los servidores nuevamente. Lo habíamos hecho en el pasado, ¿cómo podemos empezar a hacerlo de nuevo? Bueno, personalmente, no me gustaba configurar Webpack por mí mismo. Una de las formas más fáciles en que podíamos optar por un modo de renderización diferente era usando un meta framework. Y cada framework tenía su propia versión de un meta framework. Así que para aquellos de ustedes que no están familiarizados, meta framework, se llama meta framework porque es un framework construido a partir de un framework. Y bueno, esos frameworks tenían sus propios meta frameworks, Vue tenía Nuxt, Angular tenía Analog, React tiene Next.js o Remix. Y estos meta frameworks les permitieron hacer esta cosa que necesitábamos, que era la renderización del lado del servidor, tenían estos múltiples modos de renderización que podías usar.

Ahora, mientras esto estaba sucediendo, mientras esta discusión surgía, la gente comenzó a preguntar la pregunta, está bien, ¿qué pasa con Solid? ¿Dónde está el meta framework de Solid? Bueno, miren, en 2021, Vite 2.0 salió. En esa misma semana, Ryan Carnearo, el creador de Solid.js, comenzó a trabajar en el nuevo meta framework para Solid, Solid Start. Y ese es el título de esta charla, Solid Start, la Forma de los Frameworks por Venir. Antes de continuar, permítanme presentarme rápidamente. Mi nombre es Daniel Alfonso, soy un defensor de desarrolladores. Soy parte del equipo de DX de Solid.js. Soy instructor en Agileio y pueden encontrarme prácticamente en cualquier red social, en cualquier lugar en internet con el handle DanielJCAlfonso. Algunas otras cosas sobre mí, bueno, publiqué un libro llamado State Management with React Query el año pasado.

Ha estado alrededor por un año ahora mismo, bueno, el tiempo pasa muy rápido. Lancé un curso en AGet llamado An Introduction to the React Testing Library en diciembre pasado. Y de hecho, no está en esta diapositiva, pero de hecho acabo de lanzar un nuevo curso en Aget llamado Get Started with Solid Start. Así que después de esta charla, si quieren saber más sobre Solid Start, pueden escanear este código QR aquí y podrán ver todos estos cursos.

Una cosa interesante sobre este curso, es gratis para todos, así que si quieren revisarlo, por favor háganlo y denme su opinión. Algo más sobre mí, he estado publicando un boletín sobre lo que está sucediendo en el mundo de Solid cada mes. Así que básicamente, solo compilo todo lo que ha estado sucediendo, actualizaciones interesantes del equipo central, actualizaciones interesantes del ecosistema, cosas interesantes encontradas en línea. Así que por favor revisen estos boletines, también en este código QR, si quieren estar actualizados con el mundo de Solid.

Así que volvamos a la discusión que estamos aquí para escuchar. Y la pregunta es, ¿por qué necesitamos un meta-framework? ¿Por qué es esto importante? Porque un meta-framework, no se trata solo de múltiples modos de renderización. No se trata de mejorar la experiencia del desarrollador. No se trata solo de pautas adecuadas, adaptadores de implementación y ser opinado. Al final del día, se trata de tener un tiempo más rápido para la producción. Por eso desarrollamos. Por eso nos pagan para hacer nuestro trabajo. Se entrega a nuestros usuarios. Y obviamente, todos quieren que sea más rápido. Así que un meta-framework básicamente abarca todas estas cosas, para que al final del día, podamos tener un tiempo más rápido para la producción, mientras tenemos más calidad en nuestro código y un montón de otras cosas.

Ahora, hay una palabra clave aquí que, bueno, algunas personas en el mundo de JavaScript pueden ponerse un poco incómodas, y esta palabra es opinado. Porque lo que sucede es que cuando la gente escucha la palabra opinado, comienzan a pensar, oh, si soy opinado, no hay libertad, porque ahora estoy atrapado. Ahora no puedo cambiar algo, porque este meta-framework me está bloqueando en algo. Algo que he aprendido sobre el mundo de JavaScript en los últimos años es que no nos gusta ser opinados. Nos gusta ser libres. Nos gusta sentir que podemos tener la opción de traer una nueva biblioteca si queremos, para hacer algo con lo que estamos luchando. Y cuando hablamos de un meta-framework, hay cosas que van desde lo más opinado hasta lo menos opinado. Así que estas son las cuatro cosas que típicamente se necesitan para cada meta-framework. Tenemos el router, tenemos el framework, tenemos el bundler, y tenemos el tiempo de ejecución del servidor. Y como pueden ver, el router está en la parte superior de lo más opinado, porque, bueno, el router puede ser visto también como uno de los corazones de su meta-framework, y es el donde comienzan la mayoría de las opiniones y las invenciones.

Ahora, volvamos a la pregunta con la que comenzamos esta charla, que es, ¿qué pasa con Solid? Hola? Hola? Hola? Este mayo, Solid Start fue lanzado. Y ahora estamos actualmente en la 1.06, si no me equivoco.

Así que ahora podrías estar pensando, espera, ¿no dijiste que comenzó a desarrollarse en 2021? Tomó tres años para que Solid Start saliera, porque en el equipo de Solid queríamos que Solid Start fuera... ¿Hola? ¿Hola? ¿Hola? Una forma de frameworks, cuidado. ¿Hola? Queríamos que Solid Start fuera algo no opinado que pudiera darnos la mejor experiencia de desarrollador y aún así dar el control a ti, el desarrollador. Pasamos por dos fases beta, algunas grandes reescrituras de API. Pero al final del día, terminamos con algo que creemos que puede ser esto que afirmamos ser la forma de los frameworks por venir. Pero veamos un poco más sobre Solid Start. Porque hay esta diapositiva aquí. Podría ser una diapositiva inspiradora de una charla inspiradora. Esto es literalmente cómo pienso sobre Solid Start. Porque Solid Start está destinado a ser una forma no opinada de iniciar tus aplicaciones, y está destinado a ser eso, un iniciador. Está destinado a ser optativo en cosas. Por ejemplo, una de las cosas realmente emocionantes sobre Solid Start, ni siquiera necesitas un solid router. Y recuerda, el router es lo más opinado en el meta-framework. Hablé sobre eso. Pero para Solid Start, si no quieres usar el solid router, no tienes que hacerlo. Puedes traer tu propio router. Puedes traer time stack router, por ejemplo, si es compatible, cuando sea compatible con Solid Start. Así que se trata de moldear tu camino. Se trata de moldear tu viaje. Se trata de no tener cosas que no necesitas en tus aplicaciones. Porque eso sucede con más frecuencia. Solid Start se trata de elegir tu propio camino.

Ahora, veamos un poco cuál es el corazón y qué toma Solid Start. Así que en la parte superior tenemos Solid Router. Recuerda, te dije que Solid Router es opcional. No lo necesitas. Puedes descomponerlo y traer algo más. Luego tenemos Seroval, que es nuestro increíble serializador. Tuvimos que integrarlo nosotros mismos y crear un nuevo serializador para Solid Start específicamente porque hay muchas cosas interesantes que Solid Start necesita y Seroval es realmente importante para eso. No hablaré de esto porque no tendremos tiempo, pero si, por ejemplo, has asistido o has visto React Summit este año en Ámsterdam, Attila Fassina, uno de los miembros del equipo de Solid DX también, hizo una muy buena charla sobre Solid Start también, y profundizó un poco más en Seroval, así que definitivamente recomiendo que veas esa charla.

Luego también tenemos Solid. Obviamente, necesitamos el framework. Así que Solid es el corazón de Solid Start. Y luego tenemos Vinci. Así que Vinci, es un envoltorio alrededor de Vite y Nitro porque necesitábamos algunas configuraciones adicionales y tuvimos que crear Vinci. Así que uno de nuestros miembros del equipo principal creó Vinci para manejar las necesidades de Solid Start y es lo suficientemente poderoso como para soportar Solid Start y también soportar cosas como 10Stack Start, que se lanzará muy pronto. Estoy realmente emocionado por eso. Pero, como dije, es un envoltorio alrededor de Vite y Nitro, Vite siendo el entorno de desarrollo y Nitro siendo nuestro tiempo de ejecución del servidor. La razón por la que elegimos Nitro es porque es, una vez más, lo suficientemente poderoso para impulsar analog e impulsar Next. Y construye esta conexión entre comunidades. Creo que esta es una de las cosas realmente geniales de tener Nitro como nuestro tiempo de ejecución del servidor. Porque nos estamos ayudando mutuamente a crecer. Estamos creciendo juntos. Nos estamos apoyando mutuamente. Y cuando alguien de analog arregla algo en Nitro, afectará a Next. Afectará a Solid Start. Y trae este apoyo comunitario que no he visto hasta ahora en muchas cosas. Así que es realmente emocionante.

Ahora, basta de hablar sobre lo que hace funcionar a Solid Start. Podrías estar pensando, está bien, ¿qué hay de las características? Bueno, hay todas estas características. Hay muchas de ellas.

Hay muchos de ellos. No tendré tiempo para repasarlos todos, pero quiero mostrarte una pequeña demostración donde los revisaremos. Así que tengo esta aplicación aquí, donde básicamente tienes tu lista de Pokemon, y puedes atrapar tu Pokemon. Así que si voy aquí y digo, está bien, quiero atrapar a Charizard. Y el número de imagen es seis. Controlo Master Ball. Y ahora tengo a Charizard en esa lista. Eso es básicamente lo que hace esta aplicación.

Veamos cómo se traduce esto en código. Así que abramos Visual Studio Code aquí. Así que aquí tenemos una demo de Solid Start. Y comenzaría típicamente en nuestra configuración de la aplicación, donde tenemos nuestra configuración definida y estamos diciendo, está bien, esta no es la aplicación renderizada del lado del servidor. Así que tenemos servidor como falso. Esto significa que estamos haciendo una aplicación de una sola página, como la tradicional que tenemos. Y si revisamos nuestro app.tsx, así que el punto de inicio de nuestra aplicación, tenemos nuestro enrutador. Así que en este caso, estamos usando Solid Router. Recuerda, no necesitas Solid Router, pero eso es lo que estamos usando aquí.

Estamos usando File Routing. Así que File Routing, es muy útil para ayudar a hacer cosas como la carga diferida automática para algunos componentes. Así que esto realmente ayuda cuando estás haciendo tree shaking. También es bastante útil cuando tienes una aplicación grande, y no necesitas básicamente importar todas las rutas aquí, cargarlas de forma diferida tú mismo, agregarlas aquí. Este componente simplemente irá. Así que File Routing, File System Routing básicamente le dice a tu aplicación, oye, en lugar de hacerme cargar todos los componentes, vas a mirar en nuestra fuente. Vas a mirar en una carpeta llamada Routes, y vas a convertir las rutas allí en básicamente rutas para mi aplicación. Y cada ruta se carga luego dentro de este límite de suspense que tenemos aquí. Así que cuando voy a la ruta de índice, que es básicamente esta ruta que tenemos aquí, lo que va a pasar es que Solid Start, va a convertir este componente de índice en sí mismo en la ruta de índice. Si voy a la ruta Catch Pokemon, se va a convertir en la ruta slash Catch Pokemon. Ahora, eso no es lo que quiero mostrarte, solo mostrando un poco de algunas de las cosas que tenemos aquí.

Veamos qué estamos haciendo en esta aplicación. Así que primero en nuestra página de índice, estamos haciendo algo, está bien, tenemos Pokemons y tenemos Create a Sink, que es uno de los primitivos de Solid que convierte una promesa en una señal.

Y básicamente estamos diciendo, está bien, quiero obtener Pokemons. Y mientras estamos obteniendo Pokemons, porque eso es para lo que es útil suspense, tenemos un fallback para mostrar Pokedex de carga. Una vez que tenemos nuestros Pokemons, mostramos nuestra lista de Pokemon. También tenemos algo aquí, que es básicamente, un poco de información para que el enrutador sepa, está bien, cuando entres en esta ruta, puedes precargar algunos datos. ¿Y por qué es esto útil? Bueno, imaginemos típicamente el proceso típico de obtención de datos y carga de componentes. Así que nuestra aplicación se carga y nuestro índice comienza a renderizarse. Si ese índice tiene un componente, ese componente luego se obtiene y se renderiza, y si ese componente luego necesita algunos datos, esos datos serán obtenidos. Y como puedes ver, estamos teniendo una cascada.

Ahora, cuando tenemos precarga, básicamente le estamos diciendo al enrutador, oye, este componente aquí va a necesitar ciertos datos. Y lo que va a pasar es que en lugar de que el componente vaya uno, dos, tres, y luego en la parte tres obtenga los datos, el enrutador sabe que, está bien, si este componente necesita estos datos, vamos a obtenerlos en paralelo. Así que en lugar de ir uno, dos, tres, simplemente vamos uno, dos. Y esto comienza, básicamente empezamos a deshacernos de las cascadas de red. Y es una optimización para obtener datos. Ahora, lo que sucedería tradicionalmente aquí, si no hicieras nada más, es que obtendrías datos aquí, y los obtendrías aquí. Y ahora estás pensando, está bien, pero ahora tenemos dos solicitudes. Bueno, por eso introdujimos esta nueva cosa que tenemos dentro de esta función getPokemons, que se llama caché. Así que esto es un caché, pero podrías pensar en esto como un mecanismo de deduplicación de recursos.

Así que evitando el mecanismo de duplicación de recursos, lo que está sucediendo aquí es que cada vez que se llama a esta función getPokemons, vamos a obtener los datos y luego almacenarlos en caché debajo de esta clave de caché llamada Pokemons. Esto significa que si en ese viaje de ida y vuelta que está sucediendo en el navegador, si estos datos se obtienen, una vez se almacenarán en caché durante ese viaje de ida y vuelta. Y la próxima vez que suceda esa solicitud, simplemente la servimos, esos datos, en lugar de volver a obtenerlos. También hay algo realmente interesante que tenemos aquí. Así que tenemos esta directiva llamada useServer, que es algo para hacerle saber al empaquetador que queremos ejecutar esta función en el servidor en lugar de ejecutarla en el cliente. Así que significa que cada vez que se llama a esta función getPokemons, este bloque de código aquí se va a ejecutar. Va a suceder una llamada RPC del cliente al servidor. El servidor obtiene los datos, los devuelve al cliente y luego el cliente tiene acceso a ellos y los almacena en caché. Eso es básicamente lo que está sucediendo aquí en esta parte. Y como puedes ver ahora mismo, acabamos de ver algo bastante genial en solo dos minutos. Hemos visto la precarga de datos, hemos visto el enrutamiento del sistema de archivos, hemos visto el almacenamiento en caché, hemos visto funciones del servidor. Vamos a revisar la parte de catchPokemon. Así que el componente catchPokemon es básicamente solo un formulario.

Y es un formulario que tiene una acción de formulario. Recuerda, los formularios han sido los pilares de las mutaciones en la web desde siempre. Y una acción es básicamente solo algo que el formulario llamará cada vez que se envíe.

Vamos a revisar esta acción. Así que sabemos, en primer lugar, que esto es una acción porque la estamos etiquetando con una acción. Y lo que estamos haciendo aquí es, una vez más, llamar a useServer. Así que ahora tenemos una acción del servidor. Y básicamente estamos obteniendo los datos del formulario para atrapar un Pokemon, lo que significa agregar esos datos a nuestra base de datos. Y luego le decimos al navegador, está bien, una vez que hayas agregado estos datos, regresa a la ruta anterior.

Así que no queremos quedarnos en el formulario. Y esto va a llevar a una característica muy interesante. Porque ahora quiero que te concentres en antes de que tomemos de nuevo. ¿Qué sucedería tradicionalmente? Así que tenemos nuestro formulario. Entonces, cuando enviamos el formulario, normalmente hacemos nuestra solicitud POST, ¿verdad? Así que hacemos la solicitud POST. Y luego tendríamos que navegar a nuestra ruta para regresar. Así que ahora tendríamos que navegar. Así que iríamos al índice. Una vez que estamos en el índice, ahora necesitaríamos nuestros datos. Así que tendríamos que volver a obtener los datos. Ese es típicamente el proceso. Así que POST, navegación y obtención de datos. Así que tres solicitudes.

Así que quiero que vayas a revisar la aplicación conmigo. Porque ahora voy a abrir la pestaña de Red por un momento. Y quiero mostrarte algo interesante. Déjame solo verificar si la aplicación sigue funcionando. Está bien. Debería seguir funcionando. Lo está. Hola.

Tuve que cerrar la aplicación y comenzarla de nuevo. Pero vamos a comprobarlo. Así que vamos a atrapar un Pokemon, ¿de acuerdo? Vamos a limpiar todo. Vamos a atrapar un Pokemon. Vamos a intentar con Wukario. Así que Wukario. Y creo que el número de imagen debería ser 448. Espero no estar equivocado, pero no importa. 448. Lo lanzamos. Y atrapamos a Wukario.

Ahora hay algo interesante sucediendo aquí. Porque solo hay una solicitud. ¿Por qué? ¿No deberían ser tres? Bueno, esto es lo que llamamos mutaciones de vuelo único. Y es una de las características que, hasta ahora, solo he visto comenzar a. Lo que está sucediendo aquí es que, cuando tienes una aplicación que conoce tus dependencias del router y sabe lo que necesita suceder, lo que sucede es que, cuando hacemos esa solicitud POST, porque el router sabe dónde está, a dónde necesita ir y dónde sucede, mientras la solicitud POST sucede, ya devolvemos la siguiente página, y comenzamos a obtener los datos en paralelo y los transmitimos de vuelta. Todo en un solo vuelo. Y esto evita tener las tres solicitudes que tradicionalmente tendríamos. Y es realmente, realmente emocionante.

Desafortunadamente, no tengo más tiempo para mostrarte más cosas. Pero esto es, con suerte, solo algo para darte un rápido vistazo de cómo funciona SOLIDSTART. Así que déjame terminar mi presentación. Como puedes ver, SOLIDSTART, definitivamente no es un framework, pero te da libertad. No es automatizado. Te da esta libertad de hacer las cosas que quieres con lo que quieres. Y como dije, está destinado a ser un iniciador, destinado a ser una forma para que comiences tu viaje y hagas tus cosas de la manera que lo necesites, como lo necesites. Por eso decimos que SOLIDSTART es la forma de los frameworks por venir. Es tener algo que no es dogmático. Te da la libertad de elegir tu camino. Y estamos realmente emocionados de ver cómo esto va a afectar otras cosas. Ya estamos viendo otros meta-frameworks siendo construidos sobre SOLIDSTART en el ecosistema SOLID lo cual es realmente, realmente emocionante. Así que dicho esto, soy Daniela Fons. Muchas gracias por ver mi charla. Y si quieres conectarte conmigo en línea, Daniela J. Ciafonso en todas partes. Nos vemos. Que tengas un buen evento. ¡Adiós!