Charla informal sobre Recoil

Muchas gracias por recibirme. Definitivamente es emocionante poder charlar. Lamento que el lugar donde me hospedo no tenga una chimenea. Tendremos que fingir. Sí, acabo de mudarme a Praga ahora porque estuve durante las vacaciones en Rumania y ahora estoy en Praga. Pero aquí es mucho mejor. Debo decir que el clima es mucho mejor. Estoy muy contento de tenerte aquí. Estaba escuchando tu charla sobre Recoil.js y es muy interesante. Quiero decir, hay tantas soluciones de gestión de estado disponibles, ¿verdad? Pero Recoil, ya que viene de Facebook y especialmente de ti, es realmente genial verlo. Pero antes de cualquier cosa, ¿podrías darnos algunos detalles sobre quién eres, qué haces y cuál es tu trabajo diario básicamente?

Lo mismo ocurre con Relay. Recoil es algo que podría ser útil y si te resulta útil, entonces estamos muy contentos de ponerlo a disposición. Pero su futuro a largo plazo es incierto.

Muy bien. Sí. Quiero decir, puedo ver Recoil y decir que definitivamente es la respuesta, con mayúscula T, mayúscula F, ¿sabes a lo que me refiero?

En cuanto a esas pequeñas actualizaciones, vi recientemente que Recoil se actualizó a la versión 0.2, ¿verdad? Mm-hmm. ¿Podrías contarnos más sobre las mejoras que hicieron ustedes o tú hiciste en general y qué errores se corrigieron en general? Sí. Claro. Las dos principales mejoras en la versión 0.2 fueron una nueva implementación de selectores que es mucho más robusta y soluciona varios errores que probablemente la mayoría de las personas no habrían encontrado, pero que podrían haber encontrado. Y luego es mucho más rápido si tienes un número muy grande de átomos. Entonces, si tienes miles, decenas de miles de átomos, se ralentizaría. Y ahora eso debería ser mucho mejor, lo cual realmente usamos en ciertas aplicaciones que usan Recoil. Tendremos, digamos que tienes un documento y cada elemento en el documento está representado por un átomo, ¿verdad? Ese es el tipo de cosa para la que está diseñado y que ahora funciona mucho mejor.

En cuanto a los selectores, algo único de los selectores de Recoil es que pueden tener dependencias dinámicas. Cada vez que ejecutas el selector, no es que haya declarado estáticamente un conjunto de otros átomos o selectores de los que depende. Y solo para retroceder un poco, si las personas no están familiarizadas con esto. Un selector, la forma en que lo entendemos es como una función, es una función pura de algún otro estado que simplemente tiene información sobre qué estado necesita para que cuando ese estado cambie, esa función se reevalúe. Así que, como los componentes pueden suscribirse al estado, pero también pueden suscribirse a una función de estado, si eso tiene sentido. Entonces terminas con este gráfico, este, como un gráfico de flujo de datos, y las cosas fluyen desde el estado hacia abajo a través de estas funciones y en los componentes. Y la mayoría de las cosas que hacen algo así, la forma de ese gráfico se conoce de antemano. Pero en Recoil, puede cambiar. Es una función, técnicamente, del estado, así que no es, como, caos. En un estado dado, el gráfico tendrá una forma particular. Descubres eso evaluando los selectores, y luego cuando se ejecutan, pueden decir, necesito este data, necesito este data. Pero eso puede ser condicional. Entonces, en un estado, se suscribe a algún data, y en un estado diferente, no lo hace. Hasta ahora, todo bien. La forma básica en que querrías implementar selectores es que, como, si estuvieras, ya sabes, sentado, pensando cómo hacer esto, tendrías una caché donde las entradas son, como, conjuntos de dependencias. Estas fueron mis dependencias, estaban en este estado, así que aquí está el valor que obtuve.

Eso no funciona realmente si tienes dependencias dinámicas, porque una evaluación particular de un selector, si es asíncrono, el conjunto de dependencias que tiene, y por lo tanto la clave de caché que debería tener, en realidad cambiará durante la ejecución asíncrona de ese selector. Y básicamente es solo este gran rediseño de todos esos conceptos. Tienes la ejecución de un selector y luego tienes el valor que se ha evaluado para un estado particular en un momento particular. Y esas son dos cosas diferentes.

En realidad, suceden muchas cosas. El resultado de eso es simplemente que había muchos casos especiales que podían ocurrir con selectores asíncronos que ahora están solucionados. Así que eso debería ser una característica realmente robusta.

OK. Entonces, en relación con los selectores, Jyrock94 hizo una pregunta: ¿hay patrones o problemas comunes al crear selectores que puedan causar una disminución del rendimiento o renderizaciones innecesarias? Sí. Creo que lo principal a tener en cuenta es que Recoil se basa en la idea de que separemos nuestro estado en pequeños átomos individuales, a diferencia de si lo estuviéramos pensando de la manera en que podríamos hacerlo en Redux u otros sistemas, donde tenemos un gran almacén negro con todo nuestro estado en él. Es una unidad y se actualiza atómicamente. Luego tenemos selectores que extraen pequeñas partes, como esta parte que va a ser utilizada por este componente. Esta parte que va a ser utilizada por este componente. Entonces los están seleccionando. ¿De acuerdo? Ese enfoque eventualmente alcanza un límite de escalabilidad porque, en los selectores, cada vez que cambia cualquier estado, debes evaluar todos esos selectores nuevamente para ver si las cosas que están aguas abajo de ellos necesitan actualizarse. Por lo tanto, no quieres encontrarte en una situación así, y Recoil no optimiza eso en absoluto, si eso es lo que estás intentando hacer. Por lo tanto, no se saldrá temprano si tienes un selector cuyo valor no cambia. Entonces, la forma en que debes hacerlo en Recoil es tomar las cosas en tu estado que se actualizarían de forma independiente y separarlas en diferentes átomos. Eso es lo principal con lo que veo que la gente se encuentra. Por lo tanto, debes dividir el estado en piezas pequeñas y Recoil te proporciona una API que te permitirá actualizarlas juntas como una sola unidad.

Genial, tengo otra pregunta sobre la nueva actualización. Recoil anteriormente no tenía dependencias, ¿verdad? No había dependencias de terceros y en la versión 0.2 se agregó el paquete hash array map tree plus. ¿Podrías ampliar eso? ¿Cuál es su propósito y por qué ayuda?

Correcto, eso se remonta a lo que dije, hay dos cambios en la versión 0.2, hablé del primero. El segundo es simplemente la mejora del rendimiento. Y eso se debe a tener una estructura de datos que te permite hacer algo similar a una copia, como si estuvieras tomando un mapa grande o un conjunto grande y copiándolo, pero sin tener que hacerlo realmente. Porque eso eventualmente te ralentizará mucho si solo estás tomando un mapa incorporado o algo así y copiándolo. Y por lo tanto, esa biblioteca implementa una estructura de datos que te permite, básicamente, si piensas en esto, probablemente sea más fácil con imágenes y si buscas en Google como árboles hash, verás esto, pero básicamente lo que quieres hacer es dividir tu estructura en segmentos que están en un árbol. Y si quieres una nueva copia de todo el árbol, solo necesitas copiar el segmento donde ocurren los cambios y todos los nodos que apuntan a eso. Esa es la idea básica. Y todo lo demás, tienes un nuevo árbol, pero en su mayoría se reduce a la misma estructura de nivel base. Y eso es lo que implementa. Y sí, es solo para mejorar el rendimiento. Si tienes un número muy grande de átomos.

Esto me recuerda en el pasado, estaba mirando Baobab JS, que es, ¿estás familiarizado con Baobab? No creo que lo esté. ¿Por qué no hablas un poco al respecto? Como el árbol. Sí, exactamente. Se basa en índices y sí, es básicamente, es como un árbol, ¿verdad? Y tienes hojas y cada vez que algo se actualiza, se propaga hacia abajo. Entonces, quien esté escuchando esos cambios recibirá una actualización. Pero es genial ver y tan valiosas bibliotecas de terceros, que son realmente pequeñas en tamaño y que pueden hacer tantas cosas buenas para Recoil y también para otras bibliotecas. Porque es una implementación.

Sí, sabes, muchas de estas cosas surgieron de la, creo que fue la comunidad de Clojure, Clojure era un lenguaje de programación j, realmente innovó mucho en torno a estas estructuras de datos persistentes y cómo usarlas en la práctica, muchas de ellas, ya sabes, si miras Recoil, definitivamente verás una similitud con algunas de las cosas que existen en Clojure script y cosas así. Y es realmente genial ver que eso se está adoptando en JavaScript, que las personas están descubriendo cómo usar esas cosas. Por supuesto, el lenguaje no permite implementar estructuras de datos como esas, si la eficiencia total de las que están implementadas dentro de la VM. Pero para ciertas aplicaciones definitivamente tienen mucho valor. Así que es genial ver que eso se está adoptando. Sí, pulgares arriba para eso.

Otra pregunta que surgió dos veces, en realidad, fue sobre el estado del renderizado en el lado del servidor en Recoil. Guido realmente hizo esta pregunta y Buhtargac, espero no haberlo escrito mal. ¿Puedes agregar algo sobre SSR? Sí, lo admitimos. En realidad, no tengo conocimiento, no he escuchado a nadie que lo esté utilizando, pero de vez en cuando recibimos informes de errores en ese escenario, así que supongo que la gente lo está utilizando y tratamos de solucionar esos errores. Básicamente, Recoil proporciona una API que probablemente quieras usar si estás haciendo esto llamada estado inicializado, que es una propiedad de la ruta de Recoil. Y cuando la usas, utiliza ese estado en la primera renderización. Y eso es lo que se utilizará para SSR. Genial. Otra pregunta de JROK94, ¿puedes descargar átomos? Si estás creando átomos dinámicamente por id y ya no necesitas ninguno de ellos, ¿quedan atrapados en la memoria? Antes de que respondas, en realidad fui a la documentación de recoil.js y mencionas allí que es algo en lo que vas a trabajar en el futuro, pero tal vez puedas decir más al respecto. Sí, actualmente, puedes hacer eso eliminándolos manualmente con un gancho llamado useResetRecoilState. Eso eliminará ese valor. Es como restablecerlo, pero en realidad lo estás eliminando, restableciéndolo al valor predeterminado. Y eso es lo que puedes hacer en este momento. Y luego tenemos algunos cambios que saldrán pronto, con suerte, que liberarán automáticamente los átomos. Optarás por ello en función de cada átomo. Dirás, quiero que este átomo se recolecte como basura, básicamente. Y cuando no esté siendo utilizado por ningún componente, se eliminará. Y estamos utilizando eso internamente. Y esperamos lanzarlo como código abierto muy pronto. Hay un ligero cambio en la API. Así que habrá una versión en la que recibirás una advertencia de que necesitas cambiar algo. Y luego otra versión donde esa característica estará activada. Un cambio realmente pequeño, no debería afectar a la mayoría de las aplicaciones en realidad.

Increíble. Otra pregunta es, ¿dónde puedo usar recoil.js? Y en tu opinión, ¿cuál es el mejor caso de uso? Si puedes expandir un poco más sobre eso también. Claro. Básicamente, quieres usarlo en situaciones donde tienes un montón de diferentes piezas de estado. No un número fijo, sino un número variable de diferentes piezas de estado que afectan a hojas distantes en tu árbol de React. Así que el árbol, la suposición básica en React es que la mayoría de las actualizaciones van a ser pequeñas o grandes. Ya sea que estés actualizando un botón porque hiciste clic en ese botón, o que vayas a una pantalla diferente y tengas que volver a renderizar todo.

En la mayoría de las aplicaciones, la mayoría de las actualizaciones se encuentran en esas dos categorías, y ambas son manejadas de manera muy eficiente por React. Donde no funciona tan bien es cuando tienes cosas que se actualizan rápidamente, pero están en partes distantes del árbol. Porque no es todo el árbol. No es una parte, sino que está aquí y allá. Ahí es donde quieres ese tipo de actualizaciones más basadas en suscripción desde algún estado que no está en una parte específica de tu árbol. Entonces puedes usarlo en situaciones como esa si lo necesitas. Pero realmente te sugiero que intentes construir solo con React y veas hasta dónde llegas. Y luego puedes agregar Recoil como un ingrediente adicional si alcanzas un límite.

Otra cosa que podrías considerar y que me sorprende que no sea más popular en el código abierto es Relay, otra biblioteca de Facebook que utilizamos mucho en Facebook. Tiene un poder realmente único, que es la capacidad de analizar un árbol de componentes de React y ver qué datos van a necesitar antes de ejecutarse, y consolidar todos esos datos en una sola consulta. Y luego puedes comenzar a cargar esa consulta mientras el cliente aún está descargando tu JavaScript. Así que antes de que el cliente tenga el código para ejecutar, para saber que debe ejecutar la consulta, ya estás calculando esa consulta, ya sabes, consultando la base de datos con ella. Y, obviamente, no puedes ser más rápido que eso. Así que si estás cargando datos y estás pensando en utilizar los selectores asíncronos en Recoil para hacerlo, verifica primero si puedes hacerlo con Relay, porque si puedes, definitivamente siempre será más rápido.

Increíble. Gracias por el consejo. Estoy seguro de que quien esté escuchando ahora y en el futuro, también echará un vistazo a Relay. Tengo otra pregunta del Sr. Oz. ¿Hay una mejor manera de actualizar los selectores asíncronos que utilizando un átomo de ID de solicitud, como el ID de solicitud? Es el ID de solicitud más uno, que devuelve el ID de solicitud más uno. Esa es exactamente la forma en que lo haría. Si eso es lo contrario, puedes tomar todo ese patrón y envolverlo en algo que los genere por ti. Creo que en realidad tenemos uno de esos. No estoy seguro si es de código abierto, pero es muy fácil. Puedes escribir eso una vez y esa es la forma de hacerlo porque eso mantiene el concepto de que un selector es una función pura de algún estado. Cuando entras en cosas, como si vas a hacer depuración en viaje en el tiempo, o algo así, o simplemente mirar el sistema, todo es una función pura. No varía con el tiempo. Estás modelando explícitamente en el tiempo, pero eso es parte de tu modelo explícito que puedes manipular. ¿Tiene sentido?

Sí, recuerdo cuando comencé con React, que fue hace casi ocho años, había mezclas, no había una API de contexto. Solía haber una API de contexto, que estaba oculta de alguna manera, y tenías que profundizar mucho en los entresijos de React. Pero recuerdo que teníamos un árbol tan grande que al final, teníamos tantas propiedades que estábamos enviando por el camino y básicamente cascándolas. Y teníamos tantas actualizaciones innecesarias porque estaba en medio del árbol, el componente era básicamente solo un proxy para esas propiedades, porque estábamos usando la metodología HATEOAS, que es básicamente como un explorador de API, por lo que una respuesta de API te dará más puntos finales donde puedes obtener más datos basados en el recurso actual. Básicamente, piensa en HATEEOAS como una API de puntos finales de usuario que te dará URLs de usuario 1, 2, 3 que puedes obtener hacia adelante. Así que básicamente tenemos una representación de la API mediante componentes de React. Y recuerdo que todo no era tan eficiente, por lo que teníamos que hacer trucos de actualización de componentes y pasar de alguna manera el estado del estado global, pero luego, por supuesto, aparecieron Flux y Redux, y esta solución de gestión de estado, y hoy en día es Recoil, que parece muy prometedor. Es muy fácil de usar. Simplemente fui a la documentación y pude entender casi todo fácilmente, no los detalles internos aún, pero la API general parecía muy fácil de entender.

Sí, soy un gran fanático. De hecho, tuve acceso a ella desde que estaba en privado porque tuve la suerte de que alguien fuera a la conferencia de React.js cuando se anunció en 2016. Estoy jugando con ella desde entonces. Realmente me encanta. De hecho, también la estamos usando en Skype. Así que, estamos utilizando React Native y Electron. Para la gestión del estado, tenemos nuestra propia solución que es de código abierto. Es diferente en comparación con Recoil. Pero, sí, esto es lo que nos funcionó. Y en la actualidad es bastante difícil revolucionar todo o reescribirlo todo, ¿verdad?

Sí, definitivamente. Porque es una aplicación bastante grande.

Sí. Y reescribir no es algo realmente bueno en general. Así que, sí.

Sí, requiere un esfuerzo enorme hacer eso.

Sí, exactamente. Entonces, ¿funciona? También necesitas hacer algunas mediciones. ¿Funciona o no? Sí.

Hablando de cómo empezar, tal vez haya personas que nos están viendo y les gustaría comenzar o empezar con Recoil. ¿Tienes algún ejemplo o buenas prácticas que las personas puedan seguir o consultar?

Sí, bueno, hay un sitio web. Si vas a recoiljs.org, hay documentación allí. Luego, si haces clic en enlaces externos, en la sección de ese sitio web, hay un enlace a algunos videos que alguien ha creado en realidad, que son de muy buena calidad y te guían a través de cómo hacer una aplicación de dibujo con Recoil y creo que eso es una buena introducción para usarlo. Recientemente descubrí learnrecoil.com. Sí, hay un desarrollador que está, y todo es gratuito. Él está cubriendo todo lo que necesitas saber sobre Recoil y está tratando de recrear Excalibur utilizando Recoil. Creo que eso es probablemente lo mismo a lo que me refería. Así que eso está vinculado desde el sitio web de Recoil. Exactamente. Y sí, parece un trabajo realmente bueno.

Veamos si tenemos alguna otra pregunta. Pasando a Basecamp, Preguntas y Respuestas. Otra pregunta de Dry's Capone. Creo que lo discutimos, pero solo para resumir esto, ¿deberíamos preocuparnos por la bandera experimental? ¿Se puede usar Recoil en producción? Creo que debes evaluar los beneficios y riesgos para tu aplicación en particular. No es como si fuera a desaparecer. Necesitas usar el código que está disponible. Lo usamos mucho internamente. Proporcionalmente, porque Facebook es tan grande. Podría ser una fracción pequeña, pero aún así ser muchas aplicaciones diferentes. Pero lo usamos en muchos lugares, así que tenemos una dependencia de él y probablemente seguiremos brindando soporte. Pero no tiene el mismo nivel de soporte que algo como React. Así que supongo que no puedo dar una respuesta definitiva, pero eso es más o menos el estado actual. Hay muchas personas que trabajan en ello. Es un proyecto secundario para todos nosotros. Pero lo usamos en aplicaciones que necesitamos mantener en funcionamiento, así que no desaparecerá en el futuro previsible. Sí, es realmente bueno ver que todo lo que es de código abierto por Facebook, en realidad se utiliza dentro de una aplicación de Facebook. Y esto significa mucho porque aunque sea experimental, se utiliza en producción de todos modos, aunque se pruebe con A/B y cosas así, pero es algo que está en el mundo real, como solían decir los desarrolladores. Otra pregunta vino de M. Botis.