Dentro de Fiber: la descripción general en profundidad que querías para TLDR

Por cierto, estamos ocultos. Antes de comenzar, tengo algunas advertencias. La primera es que, como probablemente puedas imaginar, el código fuente de React es realmente complejo y algunos de los pensamientos que tengo aquí son un poco especulativos. Y la segunda cosa es que tal vez no sea 100% lo que llamarías un TRDR, pero cada vez que encuentres una gran cantidad de contenido, verás este ícono, lo que significa que podemos discutir eso en la fiesta posterior o en las sesiones de preguntas y respuestas, etc. Así que no te preocupes.

Antes de comenzar, me gustaría darte un poco de contexto sobre por qué quería presentar esto y por qué quería hablar sobre estos temas. Todo comenzó con este amigo mío llamado Bruno. Estaba preparando esta propuesta para llevar efectos algebraicos a JavaScript, así que era como una propuesta regular de TC39, y me pidió algunos comentarios. Cuando estaba leyendo su propuesta, pensé que veía una gran cantidad de temas sobre los que nunca había escuchado hablar, y había esta gran nube en mi mente, como efectos algebraicos, coroutines, continuaciones, fibras, hilos, generadores, etc., y lo que quería hacer aquí era poner todo eso de manera que tuviera sentido recorrerlos y también mostrar cómo se unen todos en react.

Comenzando con las fibras y una breve descripción. La forma en que me gusta ver las fibras es pensar en una función regular de JavaScript. Tenemos esta función de suma con dos parámetros. Si pensamos en cómo se vería un marco de pila para eso, obtendríamos algo como esto. Tenemos un retorno, la función en sí, algunos parámetros y las variables locales que son los números o los resultados.

Si pensamos en un componente de React, podemos llegar a algo similar. Podemos pensar en una fibra de esta manera, donde tenemos nuestros componentes en lugar de una función, nuestras props en lugar de nuestros parámetros y luego el estado del componente como nuestras variables locales. Entonces, para empezar, podemos pensar en la arquitectura de la fibra como este modelo de pila de llamadas específico de React que básicamente brinda un control total sobre la programación de lo que se debe hacer. Y una fibra en sí es básicamente un marco de pila para un componente de React dado. Bien, llegamos a esta definición, llegamos a esta comparación con los marcos de pila regulares, ahora podemos comenzar a ver las fibras como unidades de trabajo.

Entonces, pensemos qué sucede con nuestros componentes. Una vez que nuestra plantilla pasa por el compilador JSX, terminamos con un montón de elementos, eso es lo que anotas. Lo que sucede a continuación durante la reconciliación es que los datos de todos estos elementos se fusionan en tres nodos de fibra alfa, luego hablaremos un poco más sobre ellos. Y luego, por supuesto, dependiendo del tipo, por ejemplo, puede ser un componente de función, un componente de clase, un componente de suspense, o lo que sea, dependiendo del tipo de cosa, React mismo necesita realizar diferentes tipos de trabajo. Entonces va a etiquetar estos. Y luego, cada elemento se convierte en este nodo de fibra del que estamos hablando, que va a describir para React qué tipo de trabajo debe hacerse. Esto nos lleva a esta idea de unidad de trabajo. Y debido a que las fibras son unidades de trabajo, es conveniente realizar un seguimiento, programar, pausar y abortar tipos específicos de trabajo.

Ahora que podemos abstraer eso en términos de unidades de trabajo, también podemos pensar en visualizar esas unidades. Y para esto, me gustaría proponer este primer experimento que es la inspección de elementos. Tomemos esta aplicación simple. Tengo algunos componentes con algún estado local y tengo este botón. Estoy incrementando y decrementando este estado local y eso es todo. Si comenzamos a registrar nuestras fibras en la consola, veremos esto, un montón de metadatos sobre nuestros componentes. Y veremos metadatos sobre props, estado, etc. Sé que era muy pequeño, pero no te molestes en intentar leer eso. Solo quería mostrar que hay mucha información allí. Y podemos usar, por ejemplo, este tipo de información. Aquí hay un fragmento de código donde estoy usando solo cinco de estas propiedades para iterar sobre esas fibras.

Y lo que voy a obtener ahora es, simplemente copio y pego el código en las herramientas de desarrollo y ahora tengo Twitter abierto con un perfil de cumbre rojo abierto. Y estaba iterando y almacenando eso en un mapa regular de JavaScript. Y lo que tengo ahora es que, por ejemplo, puedo inspeccionar un elemento dado de eso. Así que, como están en un mapa, puedo hacer clic en eso y encontrarlos en el mapa. Obtengo mucha información sobre los componentes.

Por ejemplo, puedo descubrir que Twitter utiliza muchos componentes de clase. Así que lo que te recomendaría explorar son esta parte del reconciliador, se llama tipos internos de React. Allí puedes ver literalmente todas las propiedades de la fibra y qué tipo de datos almacenan. Y otra parte realmente interesante es la palabra etiquetas. Porque verás que, por ejemplo, React tiene 25 tipos diferentes de etiquetas que se pueden usar para etiquetar lo que se debe hacer. Por ejemplo, un límite de error, un componente de suspense, un componente de perfil, un componente de clase o función regular. Y verás que esto sigue creciendo. La última vez, hace unos años cuando lo revisé, eran como cinco. Así que cuanto más características añade React, más ves que crecen. Ahora que podemos visualizarlos, también podemos hablar de cómo manipularlos.

Me gustaría hacer una pequeña pregunta aquí. ¿Quién aquí ha oído hablar de la homoiconicidad? Esta bonita palabra la encontrarás en Wikipedia u otros sitios que básicamente significa que es una propiedad de los lenguajes de programación en los que el código utilizado para escribir el programa se escribe utilizando las estructuras de datos de ese lenguaje. Esto es más fácil de visualizar en lenguajes como Clojure, por ejemplo, o Lisp. Pero por ahora, tomemos esto, tu código es datos y tus datos dentro del problema es el código. Lo que acabamos de ver es que los elementos de React también son solo datos. Así que podemos empezar a pensar en React y la homoiconicidad. Y al igual que Lisp y esos lenguajes que tienen esta propiedad, podemos manipular los hijos de un elemento o sus propiedades de la manera que queramos. Y esto nos permite hacer cosas interesantes.

El segundo experimento es la coincidencia de padres en React. Tengo este ejemplo de código donde básicamente tengo un componente de coincidencia y tengo un with y un otherwise. Y básicamente... Y esto está tipado. Pero lo que hace este código es intentar emparejar una respuesta de una API. Y si es un error, voy a renderizar mi componente de error. Si es una imagen...

Si está bien pero es una imagen, entonces voy a renderizar un componente y luego, si es un texto, voy a renderizar un componente diferente. Eso es la coincidencia de patrones. Y esto se construye verificando los metadatos internos de los elementos. Por cierto, el código para eso está en GitHub.

Ahora, podemos pasar a la siguiente cosa. Corrutinas. Empecé a leer sobre corrutinas después de ver este tuit de Andrew Klock. Él es de... Solía estar en React. Básicamente dijo que las suspensiones de React engañarían a la gente para que aprendieran sobre corrutinas. Y tenía razón. Y luego empecé a buscar definiciones sobre eso y vi muchas de ellas.

La primera definición es que las corrutinas son generadores o productores que también pueden consumir valores. Así que si piensas en esto, los generadores que tenemos en JavaScript también pueden consumir eso. Por esta definición, esos serían corrutinas. Otra definición que encontré es que son generadores que pueden resolver valores asíncronos. Al igual que tenemos con async await, por ejemplo. Y esta definición también es muy común en JavaScript. Porque, por ejemplo, incluso puedes recordar las corrutinas antes de que las promesas fueran realmente una cosa. Básicamente, implementaciones de promesas basadas en generadores. E incluso bajo el capó, también hace eso. Y la última definición es, como, la que tiene más palabras de moda, es que es un generador que se puede usar con una continuación de pila. Sé que suena complicado. Pero podemos pensar en esto como si tuviéramos un await profundo. Si estás familiarizado con el suspense de React, puedes pensar que puedes pausar la reconciliación en cualquier nivel de tu árbol de componentes.

En resumen, vimos las fibras y en las fibras, para resumir, tenemos rutas de control para el planificador. Por ejemplo, el planificador de React. Y este planificador va a determinar qué se ejecuta a continuación. Puede ser, por ejemplo, un nodo.

Será algo similar. Mientras que en las corrutinas, básicamente tienes rutas de control al llamador y son manejadas por tu código. Así que por el código del desarrollador. Esa es la diferencia clave entre estas dos.

Ahora podemos hablar sobre las corrutinas en React. Aparecieron por primera vez cuando se estaba trabajando en Fiber como un tipo de componente específico. Recuerda que vimos esas etiquetas donde tenías todos los diferentes tipos de componentes. Tenías otros dos que eran el componente de corrutina y el componente de uso. La idea allí, a diferencia de las fibras, era darte, como desarrollador, el control total de pausar y reanudar eso. Por cierto, hay una solicitud de extracción realmente interesante que determina la idea y cómo implementar eso y todo eso. Pero la cosa es que las corrutinas, en sí mismas, ya no existen en React para las experiencias visuales cara a cara, por ejemplo, optimizar esas y memorizar, etc., ya no existen. Pero imagino que será realmente interesante ver en qué forma iba a venir en el futuro.

Entonces, lo que podemos hacer es hablar sobre cómo las corrutinas como una abstracción podrían haber influido en React concurrente, que es una de las cosas más populares de las que estamos hablando recientemente. Si recuerdas esta charla de Dan Abramov hace unos años, él estaba proponiendo este experimento donde tenía una operación muy ligada a la CPU que ocurría en el componente y el componente se retrasaba, etc. Quiero proponer un experimento similar. Digamos que tenemos esta operación con muchos recursos y esa es la función regular de JavaScript que básicamente itera hasta un millón y luego suma los valores y devuelve una cadena. Solo piensa en ello como cualquier operación ligada a la CPU. Puede ser, por ejemplo, descifrar una contraseña. Y luego tienes el componente con muchos recursos que simplemente lo usa y renderiza el resultado. Entonces, si intentamos simular eso, verás que puedes comenzar a escribir, pero comenzará a retrasarse hasta el punto en que tu campo de entrada no responderá y luego simplemente descifrarás todo el rastro principal. Y eso es una experiencia de usuario realmente mala. Para el próximo experimento, quería recrear el mismo ejemplo pero con un planificador basado en corrutinas. Este es el código que tenemos. Voy a modificarlo un poco. Y la parte clave que verás es que ahora tengo una función generadora. Mi operación con muchos recursos ahora es un generador y agregué este while true. Sé que suena hacky, pero solo quería usarlo al comienzo mismo de la ejecución. Y ahora creé esta instancia de un nuevo planificador y estoy pasando mi operación pesada. Veamos cómo se ve esto, el código real. Puedo comenzar a escribir y verás que, por supuesto, está en suspense porque este planificador está listo para el suspense. Y verás que está en suspense mientras se está ejecutando, pero no se retrasa en absoluto.

Entonces, volvamos al código original. Y ahora hagamos esta transición de inicio que está en React 18, como probablemente hayas visto. Veamos cómo se ve esto. Verás que, sí, hizo algo al principio, pero tengo una experiencia realmente similar. Así que sí, lo hicimos usando un poco de magia de corrutinas. Y cuando empiezo a pensar en React, no se utiliza WebWorkers ni WASM ni nada para el paralelismo. Entonces, ¿cómo logra React esto? Lo que tenemos es este modelo comparativo de multitarea, donde tienes, sí, tienes un solo hilo de renderizado, pero es interrumpible. Y el renderizado puede intercalarse con otras tareas. Y también, otras tareas podrían ser otras tareas de renderizado. Entonces, en nuestro ejemplo, es así. Teníamos esta tarea de renderizado original, y luego teníamos esta entrada de usuario que, por supuesto, tiene alta prioridad para que la interfaz de usuario sea receptiva. Y luego tienes la prioridad correcta para manejar la prueba, pero luego puedes reanudar el original Y lo genial es que cualquier actualización puede ocurrir en segundo plano. Entonces, no bloquearía la respuesta a la nueva entrada. Y el planificador no es lo suficientemente inteligente como para cambiar al más utilizable, luego después de que termine, reanudar el otro que tenías. Y mi hecho favorito al respecto es que cede la ejecución al hilo principal cada cinco milisegundos. Y la primera vez que me di cuenta de esto, pensé, bueno, ¿pero por qué cinco? ¿Es como esos números mágicos de CSS que usamos a veces? Y no lo es. En realidad, la cosa es que es lo más pequeño que se puede ajustar en un solo fotograma, incluso en dispositivos de 120 FPS. Por eso se siente como si no bloqueara las animaciones. Y para ser honesto, lo segundo es que la mayoría de los componentes individuales no tardan más que eso. No es como si, a diario, tuviéramos que iterar hasta un millón en nuestros componentes o algo así. Así que en la práctica, sí, el renderizado es efectivamente interrumpible.

Y una de mis partes favoritas, los manejadores de efectos, así que una descripción general de eso es que estaba buscando eso cuando lo vi por primera vez, vi que básicamente los efectos son esta cosa que pide al entorno de llamada que maneje una tarea específica. Y cuando se utiliza un efecto, se llama al manejador de efectos más cercano y luego te permite ejecutar algún código en respuesta a esto.

Luego, Abramoff tiene esta publicación llamada efectos algebraicos para el resto de nosotros que es realmente interesante. Y el ejemplo de código que utiliza, esto no es código JavaScript, es como código imaginario de JavaScript. Y lo que estamos haciendo aquí es simplemente tener un componente regular, tener una función regular, estamos obteniendo este nombre y veremos este perform hacia. Y luego este handle effect, así que estamos realizando algún efecto y luego lo estamos manejando. Y si pensamos un poco, esto suena como throw, try, catch, pero en lugar de throw tenemos perform y en lugar de catch estamos manejando ese efecto. Y luego esta función resume width nos permite volver al punto donde se realizó el efecto. Por ejemplo, esto podría ser obtener algo de una database o registrar algo.

Entonces, los controladores de efectos en React, aparecen mucho a lo largo de toda la historia. Todo comenzó con el algoritmo de diseño. Hace años, puedes revisar esto. Es todo un tema, pero para resumir, se experimentó con construcciones basadas en controladores de efectos para rediseñar la forma en que React realizaba el diseño. Avancemos en el tiempo cuando se reconstruyó la API de contexto, así que si piensas en cuando React 16.3 salió, teníamos una nueva API de contexto. Cuando estaban experimentando para crear eso, también utilizaron la idea de los controladores de efectos para construirlos. Pero nuevamente, problemas con la memorización y otras optimizaciones impidieron que se lanzara eso con los controladores de efectos. Aun así, es realmente interesante revisar esto.

Nuevamente, con el manejo de efectos secundarios dentro de un componente. Esta es una propuesta de otro miembro del equipo principal. Un ejemplo realmente similar. Y nuevamente, donde tienes el mismo patrón, pero en lugar de lanzar rayos, en lugar de capturar, capturando efecto. Ahora, mi parte favorita de eso. ¿Quién aquí ha construido alguna vez una API lista para suspense? Estás construyendo un SDK y quieres que las personas lo usen con suspense. Oh. Te recomendaría que revises este, por ejemplo. Eso es React cache. Pero no tiene que ser React cache. Solo revisa cualquier API lista para suspense que uses. Por ejemplo, React fire o cualquier otra cosa. Verás el mismo patrón. Un componente es capaz de suspender la representación al lanzar una promesa, que es capturada y manejada por el framework. Esto suena complicado, pero en realidad fue la forma en que tuvieron que imitar los controladores de efectos. ¿Y cómo? Porque tienes el mismo patrón throw, handle, resume, pero en forma de componentes de React.

Algunas conclusiones sobre eso. Supongo que la primera es que React Fiber fue una reescritura de React, todo el núcleo de React, enfocada en brindar más control para la ejecución a nivel de bajo nivel. Tenemos fibras como una forma cooperativa de manejar la ejecución a nivel de bajo nivel, y tenemos efectos algebraicos como una forma de manejar los efectos donde ellos y su comportamiento son independientes.

Lo segundo que podemos ver es que React intenta abordar en gran medida la falta de esos recursos a nivel de lenguaje, porque JavaScript no los tiene, mediante la implementación de soluciones alternativas. Cada vez que los revisamos, pensamos: `ok, esto suena como una solución chapucera o una solución alternativa`, pero no, es porque el lenguaje aún está evolucionando y carece de recursos, y esas son formas creativas de tenerlos. Como consecuencia, podemos ver que comprender esos aspectos internos y las razones detrás de ellos nos permite crear nuestras propias abstracciones. Por ejemplo, el patrón de coincidencia de patrones o el planificador basado en Cool Routines que no solo fue responsable sino que mejoró mucho el rendimiento de nuestro componente en el ejemplo.

Para las siguientes conclusiones, me gustaría mencionar esta charla de Rich Harris de hace años. Se llama `Repensando la reactividad de React` y en esta charla explica todo el motivo por el cual React no es reactivo, y creo que tiene razón. No es reactivo, pero se siente cada vez más concurrente, y eso es increíble. Para una de mis últimas conclusiones, me encanta este tweet. Es de hace años y años. Fue de Gisela Mahosh, y dijo que React es una idea tan buena que pasaríamos la próxima década explorando sus implicaciones y aplicaciones. No podría estar más de acuerdo, porque el hecho de que estemos aquí, muchas personas discutiendo todos estos conceptos porque todos de alguna manera se relacionan con React, muestra que React es este agente democrático de difusión de ese tipo de conocimiento que no es tan popular en el mundo del front-end. Realmente me encanta eso. Y para mi última conclusión, tengo esta imagen. Y dicen que una imagen vale más que mil palabras. Así que esta soy yo hace ocho años en una reunión de iOS, diciéndole a los desarrolladores de iOS que Ionic o Angular serían todo el futuro del desarrollo. Supongo que la última conclusión es que no siempre confíes en todas mis especulaciones y predicciones futuras. Estas diapositivas estarán disponibles en mi perfil de Speaker Rack. Eso es todo. Muchas gracias por estar aquí. Y se siente genial tener estos eventos de vuelta. Gracias. Muchas gracias. Ahora, antes de que todos se apresuren a almorzar, tengo esta taza enorme llena de monedas de React. Recuerda, si recoges la mayoría de las monedas de React, puedes obtener un premio. Quédate. Descubrirás cómo quitármelas. Pero muchas gracias por tu charla. Realmente la disfruté.

Realmente lo disfruté. Vamos a abordar algunas de esas preguntas. Entonces, al lanzar una promesa para el suspense, ¿también se pueden usar los hooks de React que almacenan data en la fibra en los mismos marcos de pila? No estoy seguro de entender esta pregunta. Dice que lo reformule, tal vez. Volveremos a esa pregunta. Pero pasemos a la siguiente pregunta sobre si capturar errores es una operación costosa. Hasta donde sé, no. Para ser honesto, nunca lo he comprobado con pruebas de rendimiento, pero hasta donde sé, no. Probablemente esta pregunta se deba a las cosas que mencioné. La dificultad de memorizar cosas, etc. Pero esto se relaciona más con la forma en que se abstraen esos conceptos que con la captura de errores en sí. Por ejemplo, esta fue la razón, por ejemplo, por la que la propuesta de efectos algebraicos no avanzó mucho, porque llegamos a la misma conclusión de que era difícil optimizar eso, pero no por la naturaleza misma de la captura de errores. Bueno, bueno.

Ahora, no tenemos más preguntas, pero solo quiero aprender. Personalmente, no he aprendido mucho sobre Fiber, así que estaba escuchando tu charla y hay tanto que me gustaría investigar y aprender más. ¿Dónde debería empezar a buscar? Una de mis formas favoritas de hacerlo es participar en discusiones con todos los IRFC y ver lo que han estado haciendo desde 18, un trabajo realmente bueno con los RFC, etc., pero revisa los PR, las discusiones, especialmente las antiguas porque ves cómo evolucionaron hasta el punto en el que están ahora. Entenderás el contexto, eso es una cosa, y revisa otros repositorios como React Basic y los repositorios de IRFC. Hay repositorios fuera del principal pero tienen mucho contenido que te ayuda a entender el contexto histórico y cómo llegaron a este punto. Eso es una cosa. La otra cosa es buscar inspiración en otros lenguajes. Por ejemplo, hay un lenguaje llamado F que implementa de manera nativa todo este concepto de manipuladores de efectos. Se llama F. Mira cómo esos otros lenguajes abstraen eso. Por ejemplo, para el tema de la homo-iconicidad, Clojure u otros lenguajes Lisp. Intenta ver cómo otros lenguajes que hicieron mucho trabajo previo en eso abstraen sobre esto y luego conecta lo que ves del trabajo previo en el equipo de React y trata de unir todas las piezas.

Genial. Ahora, esto siguiente parece más un comentario que una pregunta sobre Drupal lanzando valores en lugar de excepciones. Supongo que no debemos sentirnos tan mal por React. Sí. No lo sabía, para ser honesto. Quiero decir, he trabajado con PHP en el pasado, pero no llegué a ese punto. Pero es interesante. Y por cierto, no estoy seguro si eso fue un post o solo un comentario en una discusión de PR pero Abramoff mencionó que es una lástima que hoy solo veamos suspense lanzando promesas porque es mucho más que eso. Sé que hay mucho trabajo interesante en caché, por ejemplo, que se combina con suspense. Así que yo mismo era uno de los que hacía bromas sobre lanzar promesas durante un tiempo. Pero sí, es interesante ver eso. Genial. Muchas gracias.

Ahora, antes de que se vayan, amigos, tengo literalmente cientos de monedas de React. Voy a dárselas a Matheus. Wow. Porque si van a Matheus, pueden obtener algunas de estas monedas de React de él. Sin embargo, necesitan hacerle una pregunta. Así que Matheus, pueden hacerle una pregunta aleatoria, cualquier pregunta, te estoy dejando en una situación difícil aquí. Puede ser sobre fiber, puede ser simplemente sobre tu tiempo hablando. Y vayan a hablar con Matheus en el stand de preguntas y respuestas. Claro. Y veanlo antes de ir a almorzar. Además, no lo puse en las diapositivas, pero también intercambiamos pegatinas como un extra. Intercambiamos pegatinas, sí. Él y yo intercambiamos pegatinas en el stand. Definitivamente, búsquenlo para obtener pegatinas geniales. Denle un aplauso y vayan a verlo para obtener monedas de React.