Beyond Signals: El Próximo Gran Cambio en la Reactividad Web

Soy Ryan Carniato, autor de SolidJS como habéis oído. Estoy muy contento de hablar en esta conferencia que aprecia la nostalgia de los 90 tanto como yo lo hago. Pero sí, quiero hablar hoy sobre un fenómeno que ha estado rondando el mundo del front-end durante los últimos años, las señales, por supuesto. Y si no estás familiarizado, esta no es la introducción. He estado dando esa charla los últimos años. Pero para resumir, puedes pensar en ello como una especie de hoja de cálculo. Una asignación normal representa un momento en el tiempo. Significa que al completarse, la variable A refleja la suma actual. Pero si B o C cambian, tienes que hacer la asignación de nuevo. Esta relación no se mantiene, mientras que con la reactividad, sí. A siempre será la suma de B y C, incluso cuando cambien.

Las señales son solo un conjunto de primitivas para ayudar a representar la sincronización. Y en el núcleo, solo necesitas conocer tres. Estado estándar, nuestro homónimo, señales. Estado impulsado, en Solid, llamamos a estos memos. Pero son cálculos puros basados en el estado.

Y luego efectos secundarios, que es cómo afectamos nuestro mundo. Bastante sencillo en concepto, quizás incluso familiar. Pero las consecuencias de usarlos van mucho más allá de esto. No es ningún secreto que en este punto, cuando hice open source Solid JS allá por 2018, las señales estaban lo más lejos de la mente de la mayoría de las personas. Habían estado presentes en JavaScript diría yo la mayor parte de una década en ese momento.

Pero habían caído en desuso, gracias al modelo de componentes de React. Incluso las pocas bibliotecas o frameworks con señales que habían sobrevivido las habían ocultado bajo objetos de apariencia simple. Pero con Solid JS, todo eso cambió. Y aunque no podemos atribuirnos todo el mérito del cambio, en realidad diría que el propio React, con su anuncio de hooks poco después, diciendo que las primitivas de datos están bien, fue realmente instrumental. Es difícil ignorar el impacto cuando prácticamente todos los frameworks, excepto React, han adoptado señales de primera clase en este punto.

Genial, ¿verdad? Fin de la historia. No, creo que estamos solo al comienzo de un cambio mucho más grande. Y no estoy solo en este pensamiento. La publicación anterior es de uno de los desarrolladores responsables de llevar señales a Angular. Estamos en el precipicio de la mayor revolución en cómo han funcionado las interfaces de usuario frontend en más de una década. Y no estoy hablando de IA esta vez. La IA facilita la construcción, pero solo puede usar los mecanismos disponibles para ella.

Tal como están las cosas hoy, las personas aún necesitan trabajar a este nivel arquitectónicamente para resolver cierto tipo de problemas y obtener el máximo de sus aplicaciones. Entonces, ¿qué quiero decir con todo eso? Las señales no son nuevas. Hemos podido usarlas en cada framework durante años. Incluso React. ¿MobX, alguien? ¿Verdad? Entonces, ¿cuál es el gran problema? Solo tener señales no es suficiente.

Las señales son un mecanismo para el cambio. Pero cómo las usas marca toda la diferencia. Voy a abordar esto desde algunas direcciones. Pero el hilo común de lo que hace poderosas a las señales es el conocimiento del grafo de datos que impulsa tu aplicación. Con eso, podemos hacer cosas increíbles que de otro modo no podríamos hacer fácilmente. Hoy voy a hablar mucho sobre el futuro. Muchos de mis ejemplos de código harán referencia a características futuras de Solid que pueden no haber sido lanzadas oficialmente aún. Honestamente, la API que ves hoy probablemente ya ha cambiado. Pero entremos en ello.

Desafortunadamente, no funciona de esa manera, como Joe Savona del equipo de React descubrió si viste su charla en ReactConf recientemente. Agregar signals, como agregar cualquier tipo de gestión de estado, en realidad reduce el techo de rendimiento de tu framework. Sabes, como el compilador de React podría permitirte escribir código más óptimo, pero no tiene un impacto significativo en el rendimiento absoluto. Este es un extracto del benchmark del framework JS, pero es bastante intuitivo darse cuenta de que este sería el caso.

Agregar mobX o legend state o Jyoti a React o incluso signals a React no está garantizado para mejorar el rendimiento en todos los casos. De hecho, en promedio, los hace más lentos. Podrías sorprenderte. Porque incluso con signals, todavía tienen todo su sistema para hacer sus actualizaciones de VDOM. No estás escapando de eso. Claro, en algunos casos, puedes evitar re-renderizados de componentes, pero el código óptimo estaría haciendo eso de todos modos sin la sobrecarga adicional.

Entonces, la respuesta a cómo los signals mejoran el rendimiento es el renderizado de grano fino. Es lo que puedes eliminar. Usar el grafo de React para solo actualizar lo que ha cambiado. Los componentes ya no importan. No hay DOM virtual. Necesito agradecer a Misko Hevery de Angular quick por este gráfico. No cuenta toda la historia, pero es un comienzo. Piensa en React, piensa en Felt 3. Piensa en la mayoría de los frameworks de hace aproximadamente un año.

Imagina alguna aplicación donde necesitas elevar el estado para que esté disponible en múltiples puntos como un carrito de compras en el encabezado y tal vez un botón de compra en lo profundo de tu página. Actualizas el estado, tu disparador vuelve a renderizarse en el árbol. Solo el carrito de compras realmente necesita actualizarse, pero hacemos todo este trabajo extra. Ahora, ¿qué puedes hacer? Bueno, hemos escuchado esto como un millón de veces en los últimos años. Memoizar. Puedes darte cuenta de que los datos que envías al botón de compra no están cambiando y solo ejecutas un camino. Generalmente, esto es lo que hace el compilador de React. Es lo que hizo Felt 3. La cosa es que, si el carrito ha cambiado, no hay forma de evitar que se vuelvan a ejecutar todos los componentes desde el propietario del estado hasta ese cambio.

Podemos podar ramas que no cambiaron en el camino, pero el cambio tiene que llegar a su lugar en la UI. Pero, ¿y si pudieras simplemente hacer eso? Ahora podrías estar pensando, puedo hacer eso. Mis signals en React, etcétera. Hasta cierto punto. El punto es que el punto en el que usas el signal entra en el árbol y se convierte en la nueva raíz. Sin embargo, con el renderizado de grano fino, todos los props simplemente funcionan de esa manera por defecto. Puedes declarar el estado en la parte superior de tu aplicación, en la parte inferior, pasarlo a través de diez componentes para obtener los mismos resultados exactos. No necesita volver a ejecutar todo el componente ni ninguno de sus padres, solo las partes que cambian. Toda esta categoría de ¿volverá a ejecutarse mi componente?

desaparece y la composición del rendimiento se convierte en una no preocupación. La conclusión, cuando la dependencia se decide en la lectura en lugar de la escritura, tu aplicación tiene mucho más conocimiento sobre cómo actualizar. La otra conclusión debería ser que el rendimiento absoluto no es lo más importante. Pero aún quiero resaltar que es real, y es un producto de la arquitectura, no del esfuerzo. Este año, otros dos frameworks por primera vez se han unido a nosotros en el tren del renderizado de grano fino, Svelte y Vue. Creo que en realidad han mejorado nuestra implementación de hace siete años. Entonces, si no hemos estado mirando el rendimiento en Solid realmente durante los últimos siete años, ¿qué hemos estado haciendo? Me alegra que lo preguntes. Mucho trabajo en construir nuestro ecosistema, pero una cantidad decente de trabajo para entender las implicaciones de este modelo de renderizado. Todo, desde HMR hasta SSR y la hidratación, nunca se había hecho antes con este modelo. También construimos un meta framework, presentamos al mundo las funciones de servidor en 2022, y las mutaciones de vuelo único en 2024. Pero más recientemente, hemos vuelto a nuestras raíces en Reactivity. Hablemos del siguiente tema, la mutabilidad.

Siempre hay. La mutabilidad a menudo se ve como algo malo, especialmente desde el lado de la programación funcional. Busqué en línea, y aparentemente hacen camisetas y pegatinas como esta explicando lo terrible que es. Pero este es uno de esos temas donde los compiladores y VDOMs no pueden seguir fácilmente. Honestamente, es lo que me llevó a crear Solid.js. Con la mutabilidad vienen referencias estables. No necesitas clonar todo a lo largo de un camino. Significa menos trabajo, lo cual es bueno para el rendimiento y bueno para tu cordura.

No tienen un punto en términos de mutación no controlada, pero los mecanismos de control como la segregación de lectura-escritura, sabes cómo obtener esa tupla cuando haces un hook, hacen el 95% del trabajo aquí sin ser inmutable. No es como si la inmutabilidad no tuviera sus propios problemas con la trazabilidad. De vez en cuando, escuchas una historia de terror donde alguien ha usado useEffect y se ha hecho un DDoS a sí mismo. Usualmente es un negocio o un usuario acumulando sus costos de infraestructura. Pero cuando es Cloudflare en sí, una empresa conocida por prevenir DDoS, gana mucha atención.

Esto podría haber sucedido en cualquier framework. La pérdida de igualdad referencial en las dependencias también puede hacer que los signals se ejecuten en exceso. Pero hay una razón por la que esto tiende a no suceder en soluciones de grano fino. Muchos, pero no todos los signals, frameworks, tienen un mecanismo para crear reactividad profunda. Es una parte importante de la solución. En Solid, los llamamos stores. Son proxies donde cada propiedad tiene el potencial de ser su propio signal. Y esto tiene consecuencias. Un signal como state en React es generalmente inmutable.

Pero un store anidado mantiene referencias para lo que no ha cambiado, por lo que se convierte en un objeto mutable. Esto es importante porque no quieres sobre notificar cuando las cosas cambian. Si actualizas el número de calle en una dirección de un usuario, no necesitas decirle al usuario que ha cambiado. Cada campo se actualiza de manera independiente. Es por eso que es menos probable que ocurra el DDoS, y por qué cuando actualizas el estado de un toggle de hecho en nuestra tonta aplicación de tareas, no necesitamos volver a ejecutar el componente ni hacer ninguna diferenciación. Los datos pueden llegar a las hojas sin recalcular todo lo que hay en medio.

Pero los stores son mucho más importantes que gestionar actualizaciones granulares. Algunos problemas simplemente se prestan a la diferenciación. Obtienes datos frescos de un servidor. No hay referencias compartidas allí. Si uno tiene que simplemente establecer un único, volvería a ejecutar todo. Muchos benchmarks y ejemplos de principios de la década de 2010 eran así. Los stores nos dan esta capacidad de diferenciar automáticamente los datos y solo actualizar lo que ha cambiado. Pero como habrás adivinado, hay una razón por la que los vDOMs diferencian la UI. ¿Qué pasa si no necesitas diferenciar todos los datos? La diferenciación es bastante derrochadora. Bueno, para eso es el reactor graph.

Sabemos qué se está escuchando. No necesitamos diferenciar todos los datos. Solo necesitamos los datos que tienen suscriptores. Solo imagínalo. Obtienes datos frescos, actualizas desde el servidor, reemplazas los datos antiguos, diferencias a lo largo del camino al que tu aplicación está suscrita, desencadenas actualizaciones solo en las cosas que han cambiado, y no se vuelven a ejecutar componentes. Solo exactamente lo que necesita ejecutarse se actualiza. He disfrutado tanto trabajando con stores en los últimos años, que comencé a darme cuenta de que estamos hablando de un tipo completamente diferente de reactividad que no ha sido tan explorado, y me hizo darme cuenta de que hay brechas. Hay problemas que requieren derivar datos granulares y lugares donde comienzas desde una única fuente pero quieres bifurcar o dividir la reactividad.

Es un desperdicio revisar cada fila cuando estás cambiando la clase seleccionada en una tabla. Pero no siempre es práctico incluir un isSelected en cada fila, especialmente cuando esos datos se comparten en múltiples lugares. A veces solo necesitamos proyectar datos reactivos sobre otros datos sin mutar la fuente. A veces necesitamos poder crear extensiones efímeras de esos datos, como fusiones y cambios optimistas sin comprometerlos. Así que desarrollamos un nuevo primitivo solo para eso. Los llamamos proyecciones.

Y aunque puede que no los uses muy a menudo, representan un espacio para el que nunca realmente tuvimos una buena solución antes en los frameworks de front-end. Un primitivo que es tanto granular como derivado. Ser derivado es importante porque elimina la necesidad de sincronización y de usar efectos para escribir estado. Los efectos realmente deberían ser el final del ciclo. La salida del sistema. Significa que mutarlo no mutará la fuente subyacente. Ser granular es importante ya que significa que finalmente tenemos una manera de bifurcar la reactividad.

Las señales convergen. Diferentes fuentes se juntan en valores computados. Las proyecciones expanden y dividen la reactividad de nuevo en múltiples fuentes diferentes. Si eso no te queda claro, está bien. Lo mostraré un poco más tarde. Hablando de reducir la necesidad de la mayoría de los efectos secundarios, puede ser bastante claro en los últimos años que las señales derivadas a las que escribes son bastante necesarias para mantener el estado sin llamar a efectos para establecer señales. Y honestamente, no somos los únicos. Creo que tanto Angular como Svelte han añadido estas señales vinculadas que yo llamo.

Solía llamarlas memos escribibles, pero hoy en día solo las llamo señales porque en la próxima versión importante de Solid, podrás simplemente derivar una señal de otra cosa, como props, simplemente envolviéndola en una función. Como ves en el segundo ejemplo, solo estoy envolviendo el constructor, y lo que eso significa es que cada vez que props.names se actualiza, en realidad restablecerá esa señal a ese valor. No hay necesidad de use effect. Lo más importante para evitar efectos innecesarios es tener premisa en async gestionado. Pasando a nuestro siguiente tema. Comienza con entender el papel de async y los frameworks de UI. Hay muchas herramientas para ayudar a manejar mejor async, procesar eventos o flujos, etcétera, pero para el framework de UI, lo único que realmente nos importa es mantener la consistencia dentro de lo que mostramos. Los frameworks de UI tienden a ser sincrónicos para proporcionar estas garantías, por lo que las señales son una gran elección allí. Solo nos importa async en el borde, como cómo entra o sale de nuestro sistema.

Necesitamos mantener nuestro modelo sincrónico. Siempre se reduce a la consistencia. Todas estas son opciones válidas. Incluso el tearing, que es inconsistente. ¿Alguna vez has usado un typeahead? Esa es una forma de tearing. Pero cada uno solo se aplica realmente en ciertos escenarios. La verdad es que no hay una solución única para todos, y todos estos como predeterminados realmente tienen problemas. Los frameworks han tomado diferentes decisiones aquí en términos de predeterminados, pero todos ellos realmente necesitan manejar los cuatro de estos escenarios.

¿Qué tiene que ver con las señales? Un framework de UI solo tiene responsabilidades con la UI, y lo único que necesita bloquear es no tener datos para renderizarla. Esto le da la vuelta al modelo convencional. Async se trata de lecturas, no de escrituras. Estamos tan acostumbrados a, como, establecer estados, asignar valor, actualizar, ya sabes, alguna forma de decirle al código que actualice. Pero async es más como hacer la pregunta, ¿puedo renderizar esto ya? , ¿lo que estoy mostrando está desactualizado? Mira las APIs que usamos, como use o suspense o await. Estas son lecturas. ¿Sabes qué más son lecturas?

Obviamente, las señales. La forma en que las señales pueden leer independientemente en cualquier lugar de tu aplicación, bueno, eso es un superpoder. Así que esto comienza con la introducción de tu primitivo asincrónico, una señal asincrónica derivada, para ser precisos. No necesita ser derivada, pero su núcleo rastrea las fuentes y vuelve a ejecutar y actualiza mientras comunica que el valor no está listo al resto del gráfico. Y esto es poderoso porque se aprovecha de todos nuestros beneficios detallados que hemos visto. Así que ahora vamos a entrar en algunas demostraciones. Déjame... Lo siento. Bien. Así que voy a mostrar una demostración rápida de código para mostrar de qué estoy hablando. En este ejemplo, he creado componentes apropiadamente llamados A, B y C, y como puedes ver, están anidados en la UI. A renderiza B, B renderiza C, y así sucesivamente, y C solo renderiza su propio texto. Pero cada uno de ellos obtiene sus propios datos.

No necesitamos bloquear porque esto efectivamente puede bloquear justo aquí y aún renderizar el componente B, que también puede buscar, bloquear aquí, lo que renderiza C. Básicamente, los hijos se convierten en hermanos automáticamente en este modelo, por lo que eliminamos cascadas del lado del cliente donde los datos no dependen de sí mismos solo con conocer la forma del gráfico reactivo. Pero es más que solo ser detallado. Las señales siendo tanto push como pull les dan una ventaja, siendo solo eventos tipo push, que solo saben qué se ha actualizado, pero no cómo se usa. O siendo pull, como un bead-on, que solo sabe qué se está usando, pero no qué se ha actualizado sin verificar todo. Las señales nos dan ambos beneficios.

Deberíamos estar aprovechando este conocimiento mucho más. Tengo otro ejemplo aquí. Este es un contador. Me encantan los clásicos. La idea aquí es que tenemos una señal para un contador, y luego tenemos async aquí, que va a obtener una frase basada en ese conteo. Luego tenemos un valor derivado, que es la frase en mayúsculas, como puedes ver esto está capitalizado. Luego en nuestra UI, tenemos un botón envuelto en un error boundary y un componente de suspense. Como ves, cuando lo cargamos en nuestra página, lo cargamos en nuestra frase.

Lo que hace interesante a esta API es que le gusta errar un montón. Tengo alguna posibilidad de que falle. Lo interesante de este conocimiento del gráfico reactivo es obviamente cuando podemos hacer clic en el cambio, podemos volver a buscar los datos, y puede borrar este estado de error. Lo más interesante de usar el gráfico reactivo es este botón de reintento. Dentro de nuestro error boundary, tenemos un reset. Lo que sucede cuando llamamos a reset es una pregunta interesante. Ya puedes decir que no estás en React más porque nuestro suspense boundary y nuestros error boundaries están en el mismo componente y solo estamos buscando cosas en el mismo lugar. Lo interesante es que este reintento realmente volverá a buscar los datos. La razón de esto es que ve que ha fallado, y rastrea hacia arriba en el gráfico, viendo los errores, hasta que llega a la fuente asincrónica. Luego dice, oh, supongo que falló. Debería intentarlo de nuevo. Hace todo esto. Veamos si puedo mostrar esto realmente, realmente rápido aquí desde las DevTools. Si has notado, me colé en el renderizado dentro de nuestro contador de frases y dentro de nuestro mensaje. En este ejemplo, en realidad no renderizamos el texto hasta aquí abajo. No tuvimos que cambiar esta API para que tomara promesas ni nada.

No tuvimos que cambiar esta API para que tomara promesas ni nada. Todo señales. Entiende las señales. Si ves, renderizamos el componente de mensaje. Cuando hago clic aquí, va a actualizar esto sin renderizar ningún componente. Incluso el error, cuando falla aleatoriamente, eventualmente, vamos. Error. Bien. Incluso cuando hago clic en este reintento, todavía podrá hacerlo sin volver a renderizar ninguno de los componentes nuevamente porque, de hecho, solo está usando el gráfico de datos para rastrearlo. Espero que eso sea al menos visible.

Muy bien. Volviendo al tema de la consistencia. Como puedes ver en los últimos ejemplos, Solid en realidad falla por defecto. No volvimos a suspense cada vez que hacíamos clic en el botón. En realidad mostró el estado actualizado. ¿Qué pasa si queremos bloquearlo para que podamos mantener valores en el pasado? Como React, tenemos transiciones. Y las transiciones son... Hemos tenido transiciones en Solid desde... ¿Qué versión era? Fue hace un tiempo. Allá por 2020 más o menos.

Tenemos mucha experiencia con transiciones. Lo que es realmente genial, y espero que este último ejemplo lo una todo para ti, es que he tomado una vieja aplicación de tareas. Quiero mostrar cómo se ve modernizar esto en una aplicación asincrónica moderna. Esta aplicación de tareas... Vamos a recargarla. Ahí vamos. To-do MVC. Es un clásico. Creamos una store, como he mostrado antes, y luego tenemos algunas funciones que añaden una tarea, eliminan una tarea, alternan una tarea.

Es limitado. La UI es básicamente solo un bucle que hace las cosas, y no voy a entrar en cómo el renderizado de grano fino es increíble aquí. Pero en general, si entro aquí y agrego algo de código y digo, oye, ya sabes, hace lo que tiene que hacer, ¿verdad? Si podemos marcar estas casillas, podemos eliminarlo. Esta es una aplicación bastante estándar, y básicamente, como esperas, simplemente, haces algunas mutaciones en la store. Agregas una tarea, filtras la tarea, la encuentras y la marcas como completada. Esto es bastante sencillo.

Pero ahora, ¿qué pasa si queremos hacerlo asincrónico? Ahora, si tuviera más tiempo, realmente haría este código en vivo, pero como no lo tengo, voy a simplemente adelantarme y mostrar las herramientas que hicimos hoy con una demostración funcional. Así que hacemos un par de cosas. Ahora, he creado un servidor, y el servidor es solo una especie de simulación. Es solo un array en otro archivo con algunos retrasos. Pero en general, los he expuesto a través de esta cosa de DB. Así que básicamente, ahora lo que hacemos es obtener nuestros datos del servidor, vamos a db.get to-dos en nuestro create async. Y luego derivamos nuestra store de estos datos.

Hice otra pequeña cosa, a la que llamé esto una store optimista, porque quiero actualizaciones optimistas. Si no hiciera esto, no tendríamos las actualizaciones optimistas. Pero pude tomar el mismo código exacto que escribimos anteriormente, como el set to-dos, el filtro, y mantener eso en nuestro ejemplo. Y luego simplemente envolver ese código en una transición. También soportamos funciones asincrónicas, pero tienes que hacer esta cosa divertida donde llamas start transition hoy, porque no tenemos contexto asincrónico, si alguna vez has visto alguna de las demostraciones de React recientemente. Así que solo voy a usar la forma de generador. Todavía estamos jugando con las APIs.

Pero la idea es, estableces tu estado optimista, cedes tu async, y luego le dices a tu función create async que actualice los datos. Y lo que esto hace es, sin cambiar la lógica de nuestra plantilla, sin cambiar incluso la lógica de nuestra store, obtenemos el mismo tipo de cosa inmediata donde tenemos esto funcionando, excepto que ahora se persiste en el servidor con estas llamadas.

Como dije, desearía tener más tiempo para entrar realmente en los detalles de esto. Pero pasar de lo que estamos acostumbrados, puramente del lado del cliente, a async implica solo envolver unas pocas acciones, y el resto de la lógica en tu aplicación debería permanecer igual. Esa es una especie de filosofía que he estado siguiendo con Solid por un tiempo, como cuando agregamos funciones del servidor y demás.

Como dije, esto es solo el comienzo de lo que sucede cuando tienes este conocimiento sobre el gráfico. Creo que vamos a ver mucha más evolución en este mundo, porque ahora, por primera vez, el código que escribes nos informa. Podría informar a tu IDE, puede informar a tus herramientas de IA, cómo fluye la data en tu aplicación. Y creo que estamos justo en el precipicio de la próxima gran cosa. Como dije, si estás muy interesado en esto, sigue observando el espacio. Transmito regularmente. Encontrarás los recursos que necesitas en Solidjs.com. Únete al Discord, únete a la discusión. Muchas cosas realmente geniales están sucediendo aquí. Gracias.

¿Cuándo sueles transmitir, por cierto? Usualmente los viernes. Me he movido más temprano. Solía ser los viernes por la noche, hora del Pacífico, pero ahora es el viernes alrededor de las 10 a.m., hora del Pacífico. Está bien. Genial. Veamos. Aún no hay preguntas. Vamos. Necesitamos tu ayuda aquí.

Veamos. ¿Cuánto tiempo transmites? Es gracioso, porque usualmente estás transmitiendo justo al final, y veo si puedo dejar un rate en ti. Sí, usualmente de cinco a seis horas, lo cual parece mucho. Pero las transmisiones generalmente se dividen en partes. Esencialmente, hablamos mucho sobre... Usualmente tengo un invitado o un tema principal que cubrimos durante aproximadamente una o dos horas.

Y luego paso generalmente alrededor de una hora haciendo temas de investigación. Como que construyo el framework al aire libre. Y luego termino con un This Week in JavaScript, donde hablamos sobre eventos actuales y cosas así. Oh, muy divertido. Genial. Increíble. Oh, y tenemos algunas preguntas llegando. Un montón de ellas. Entonces, la primera aquí es, ¿qué tan rápido Solid Start soportará SolidJS 2.0? Hay un plan en marcha. La hoja de ruta. Attila ha publicado eso. Creo que van a comenzar a trabajar en Solid Start 2.0, mientras Solid 2.0 todavía está en las etapas beta. Así que anticipo que será bastante rápido.

Hay algunas actualizaciones en las primitivas asíncronas, obviamente. Pero lo más importante es que hemos estado mostrando algunas de las primitivas asíncronas 2.0 en Solid Start todo este tiempo, solo a través del enrutador. Así que espero que el lanzamiento de Solid Start, después de Solid 2.0, sea casi inmediato. Increíble. Muy genial.

¿Por qué crees que React no ha adoptado señales en su núcleo? Simplemente no encaja con su modelo de re-renderizado. Están un poco en desacuerdo entre sí. Básicamente, la idea filosófica detrás de React es que el componente o la función es lo que se vuelve a ejecutar. Así que agregar señales simplemente no les ayuda de ninguna manera. El problema con eso es que quieren mirarlo e intentarlo, porque ha habido mucha presión en la comunidad. Pero significó que cuando hicieron las pruebas y demás, lo hicieron de maneras que no tendrían sentido desde una perspectiva de Signal Library. La gente debería dejar de molestar a React al respecto, honestamente.

Tienen su enfoque, y nosotros tenemos el nuestro. Es como intentar hacer que fetch suceda, o lo que sea. ¿Cómo funcionan las transiciones asíncronas con actualizaciones optimistas? Lo mostré brevemente allí. Desearía haberlo mostrado realmente, porque si eliminara las actualizaciones optimistas, no habrías visto las actualizaciones de inmediato. Así que fui directamente a la solución. Pero la esencia es que las actualizaciones optimistas son estas actualizaciones que se aplican inmediatamente, en lugar de ser retrasadas. La mayoría de los conjuntos de señales se mantienen en el pasado, hasta que todo se puede hacer como una sola transacción. Las actualizaciones optimistas actualizan las cosas inmediatamente, y luego, cuando la transición termina, se vuelve a derivar desde su fuente. La mayoría de las veces, las actualizaciones optimistas se derivan, como ese ejemplo. Tus datos provienen de un servidor. Puedes actualizar de manera granular las actualizaciones optimistas. Solo actualiza una cosa, actualiza una pieza en la UI. Cuando el servidor dice, OK, he actualizado los datos, entrarán. Las actualizaciones optimistas desaparecerán, pero en realidad diferenciará los datos, y luego, con suerte, nada ha cambiado, porque hiciste una buena actualización optimista, no falló, y entonces no se realiza más trabajo.

Es muy poderoso que podamos mantener nuestras actualizaciones de grano fino en ese tipo de modelo. Y luego se vuelve sin problemas para el usuario. Sí, exactamente.

¿Cómo comparas el contexto de React con las señales? Esto es como cuando la gente intenta comparar el contexto de React con las bibliotecas de gestión de estado. Son cosas un poco diferentes. El contexto, al menos la forma en que lo veo como un contenedor, sé que puedes usar estado en React y causar que el componente se vuelva a renderizar, pero eso es lo más... Es una forma básica y de fuerza bruta de usar el contexto, y ninguna biblioteca de estado real en React usa el contexto de esa manera. Está bien para cosas simples, pero causa muchas re-renderizaciones en el árbol. Entonces, las señales en sí mismas son solo una solución de gestión de estado.

Lo que lo hace interesante, como estaba tratando de decir en la charla, es que debido al JSX, porque cada parte es consciente de las señales, cuando pasas props, simplemente difiere la lectura hasta donde finalmente se lee. Básicamente, aplana todo el árbol, por lo que nada necesita volver a ejecutarse excepto los puntos que se vuelven a ejecutar. Esto es muy diferente de React, que piensa en esta jerarquía de componentes. Creo que la siguiente pregunta incluso insinúa eso.

¿Son las señales más fáciles de depurar que la re-renderización de arriba hacia abajo? Es gracioso. No diría que ninguna de las dos es más fácil de depurar. Simplemente funcionan en la dirección opuesta, por lo que las abordas de manera opuesta. De arriba hacia abajo, es como, OK, establezco algún estado, ¿por qué se está re-renderizando esto 20 veces? Miras un poco, y dices, OK, tal vez esto no está memorizado. Dices, OK, ¿dónde me equivoqué? ¿Pasé un objeto para hacer un nuevo objeto? Estás pasando por este camino, moviéndote hacia abajo en el sistema. Con señales, generalmente es como, ¿por qué esta cosa no se actualizó? Es exactamente lo opuesto.