Inside Fiber: la visión en profundidad que querías un TLDR para

Hola a todos. Es genial estar aquí. Hola, Ámsterdam. Hola a todos los que están en línea. Sí, soy Mateusz y esta sesión es Inside FIBR, el TRDR que querías. Este soy yo. Puedes encontrarme en todas partes como Ytacombinator y soy un ingeniero front-end senior en Medaglia y también mentoreo a personas de front-end en Tech Labs Berlin.

Por cierto, estamos escondidos. 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 llamas un TRDR, pero siempre que encuentres la gran carga 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 proporcionarte un poco de contexto de por qué quería presentar esto y por qué quería hablar sobre estas cosas. 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 vi una gran cantidad de temas de los que nunca había oído hablar, y había esta gran nube en mi mente, como efectos algebraicos, coroutines, continuations, fibres, threads, generators, etc.

Así que comenzando con fibres y un poco de visión general. La forma en que me gusta ver los fibres es pensar en una función regular de JavaScript. Así que tenemos estas funciones de suma, tiene dos parámetros, solo los sumaré. Si piensas en cómo se vería un marco de pila para eso, obtendríamos algo como esto. Tenemos un retorno, tenemos la función en sí, tenemos algunos parámetros y las variables locales siendo los números o resultados.

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

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

Ahora que podemos abstraerlos 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 inspeccionar elementos. Así que tomemos esta aplicación simple. Solo tengo unos pocos 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 nuestros fibres en la consola, vamos a ver esto, un montón de metadatos sobre nuestros componentes. Y veremos metadatos sobre props, sobre estado, sobre etc. Y sé que era realmente pequeño, pero no te molestes en intentar leer eso. Pero solo quería que vieras que hay un montón de información allí. Y podemos usar, por ejemplo, este tipo de información. Así que aquí hay un fragmento de código donde estoy usando solo cinco de estas propiedades para iterar sobre esos fibres.

Y lo que voy a obtener es, ahora solo copio y pego el código en las herramientas de desarrollador y ahora tengo Twitter abierto con un perfil de cumbre roja abierto. Y estaba iterando y almacenándolos 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 esos están en un mapa, puedo hacer clic en eso y encontrarlos en el mapa. Obtengo muchos metadatos sobre los componentes.

Por ejemplo, puedo darme cuenta de que Twitter usa muchos componentes de clase. Así que lo que te recomendaría explorar es esta parte del reconciliador, se llama React internal types. Así que allí puedes ver literalmente todas las propiedades del fiber y qué tipo de datos almacenan. Y otra parte realmente interesante es esta palabra etiquetas. Porque verás que, por ejemplo, React tiene 25 tipos diferentes de etiquetas que se pueden usar para etiquetar lo que necesita hacerse. Por ejemplo, un error boundary, un componente de suspense, un componente de perfil, una clase regular o un componente de función. Y verás que esto sigue creciendo. La última vez, hace unos años cuando lo revisé, eran como cinco. Así que cuantas más características agrega React, más verás que crecen. Ahora que podemos visualizarlos, también podemos hablar sobre manipularlos.

Así que me gustaría que levantaran la mano aquí. ¿Quién aquí ha oído hablar alguna vez de la homoiconicidad? Así que, esta bonita palabra la encontrarás como en Wikipedia o en otros sitios que básicamente esta es una propiedad de los lenguajes de programación en la que el código utilizado para expresar el programa está escrito utilizando las estructuras de datos de ese lenguaje. Esto es realmente 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 son el código. Lo que acabamos de ver es que los elementos de React son solo datos también. 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 un elemento hijos 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 con y de lo contrario. Y básicamente... Y esto está tipado. Pero lo que este código está haciendo es que estoy tratando de hacer coincidir 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 pattern matching. 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 lo siguiente. Coroutines. Comencé a leer sobre coroutines después de ver este tweet de Andrew Klock. Él es de... Solía estar en React. Y básicamente dijo que React suspends engañaría a la gente para aprender sobre coroutines. Y tenía razón. Y luego comencé a buscar definiciones sobre eso. Y vi muchas de ellas.

Siendo la primera que las coroutines son un generador o un productor que también puede consumir valores. Así que si piensas en esto, los generadores que tenemos en JavaScript, también pueden consumir eso. Así que por esta definición, esos serían coroutines. Otra definición que encontré fue que son generadores que pueden resolver valores async. 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 coroutine antes de que las promesas fueran realmente una cosa. Básicamente implementaciones de promesas basadas en generador. E incluso bubble bajo el capó, también hace eso. Y la última 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. Y sé que suena complicado. Pero podemos pensar en este como si tuviéramos deep await. Si estás familiarizado con React suspense, puedes pensar que puedes pausar la reconciliación en cualquier profundidad de tu árbol de componentes.

Así que para resumir, vimos fibers, y en fibers, para resumir, tenemos rutas de control al scheduler. Por ejemplo, React scheduler. Y este scheduler va a determinar qué se ejecuta a continuación. Puede ser, por ejemplo, node.

Será algo similar. Mientras que en las coroutines, básicamente tienes rutas de control al llamador y manejadas por tu código. Así que por el código del desarrollador. Así que esa es la diferencia clave para estos dos.

Ahora podemos hablar sobre las coroutines en React. Así que aparecieron por primera vez cuando se estaba trabajando en fiber como un tipo de componente específico. Así que recuerda que vimos esas etiquetas donde tienes todos los diferentes tipos de componentes? Tienes otros dos que eran componente coroutine y componente usado. Y la idea allí, a diferencia de los fibers, era darte a ti, el desarrollador, el control total de pausar y reanudar eso. Y por cierto, hay esta solicitud de extracción realmente interesante que determina la idea y cómo manejan implementar eso y todo el asunto. Pero la cuestión es que las coroutines, per se, en React ya no existen para las experiencias visuales cara a cara, por ejemplo, optimizando esas y memorizando, etcétera, ya no existen. Pero imagino que va a ser realmente interesante ver en qué forma esto va a surgir en el futuro.

Así que, lo que podemos hacer es hablar sobre cómo las coroutines como una abstracción podrían haber influido en React concurrente, que es una de las cosas más de moda de las que estamos hablando recientemente. Así que, si recuerdas esta charla de Dan Abramov hace unos años, él estaba proponiendo este experimento donde tiene como esta operación realmente intensiva en CPU sucediendo en el componente y el componente estaba retrasado y etcétera. Quiero proponer un experimento similar. Así que, digamos que tenemos esta operación intensiva en 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 piénsalo como cualquier operación intensiva en CPU. Puede ser, por ejemplo, descifrar alguna contraseña. Y luego tienes el componente intensivo en recursos que solo está usando eso y renderizando el resultado. Así que, si intentamos simular eso verás que puedes comenzar a escribir pero va a comenzar a retrasarse hasta el punto de que tu campo de entrada se volverá no responsivo y luego simplemente rompes toda la pista principal. Y esa es una experiencia de usuario realmente mala.

Así que, para el próximo experimento, quería recrear el mismo ejemplo como si tuviéramos un scheduler basado en coroutines. Así que, este es el código que tenemos. Voy a modificar eso un poco. Y la parte clave que verás es que ahora tengo una función generadora. Mi operación intensiva en recursos ahora es un generador y agregué este while true. Sé que suena hacky pero solo quería usarlo al principio de la ejecución. Y ahora creé esta instancia de un nuevo scheduler y estoy pasando mi operación pesada. Veamos cómo se ve esto, el código real. Así que, puedo comenzar a escribir y ves, por supuesto, está suspendiendo porque este scheduler está listo para suspense. Y ves que está en suspense mientras está ejecutando pero no se retrasa en absoluto.

No ves problemas con la experiencia del usuario. Y este es todo el código fuente del scheduler que acabo de compartir. Así que, ni siquiera son cuatro líneas. Y destacaría esta parte que es básicamente donde estoy cambiando entre tres estados diferentes. Así que, puede estar idle y luego puede estar pending y luego puede estar done. Verás que estoy lanzando algunas promises porque quiero que esté listo para suspense para que veas la ejecución de suspense. Y lo que puedes ver es que... Espera, ¿acabamos de hacer algo que suena como used transition?

Así que, volvamos al código original. Y ahora hagamos este start transition que está en React 18, como probablemente viste. Veamos cómo se ve esto. Verás que, sí, hizo como un poco al principio, pero tengo una experiencia realmente similar. Así que, sí, lo hicimos, usando algo de magia de coroutines. Y cuando empiezo a pensar en, en React, no hay uso de WebWorkers o WASM o cualquier cosa para el paralelismo. Entonces, ¿cómo se siente React así? Así que, 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 entrelazarse con otras tareas. Y también, otras tareas podrían ser otras tareas de renderizado. Así que, en nuestro ejemplo, es así. Tuvimos esta tarea de renderizado original, y luego tuvimos esta entrada de usuario que, por supuesto, tiene alta prioridad, para que la UI sea responsiva. Y luego tienes la prioridad correcta para manejar la prueba, pero luego puedes reanudar la original. Y lo genial es que cualquier actualización puede ocurrir en segundo plano. Así que, bloquearía la respuesta a la nueva entrada. Y el scheduler no es lo suficientemente inteligente como para cambiar al más usable, luego después de que termine, reanudar el otro que tenías. Y mi hecho favorito sobre eso es que cede la ejecución de vuelta al hilo principal cada cinco milisegundos. Y la primera vez que descubrí esto, fue como, OK, pero ¿por qué cinco es como, esos números mágicos de CSS que usamos a veces? Y no lo es. De hecho, la cosa es que es lo más pequeño que puedes encajar en un solo frame, incluso en dispositivos de 120 FPS. Así que por eso se siente como si no bloqueara las animaciones. Y para ser honesto, la segunda cosa es que la mayoría de los componentes individuales, no tardan más que eso. No es como si, en el día a día, 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 effect handlers, así que una visión general de eso es que estaba buscando en Google eso cuando lo vi por primera vez, vi que básicamente los efectos son esta cosa que pide al entorno de llamada manejar una tarea particular.

Luego Abramoff tiene este post que se llama efectos algebraicos para el resto de nosotros que es realmente interesante. Y el ejemplo de código que usa, esto no es código JavaScript, esto es como código JavaScript imaginario. Y lo que estás haciendo aquí es que tenemos un componente regular, tenemos 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 reanudación básicamente nos permite volver a donde realizamos el efecto. Así que esto podría ser, por ejemplo, obtener algo de una base de datos o registrar algo.

Así que los manejadores de efectos en React, aparecen mucho a lo largo de toda la historia. Todo comenzó con el algoritmo de diseño. Hace años, sí, puedes comprobar esto. Es todo el asunto, pero para resumir, estaban experimentando con eso con construcciones basadas en manejadores de efectos para rehacer toda la forma en que React estaba diseñando. Avanzando en el tiempo cuando estaban reconstruyendo la API de contexto, así que si piensas en cuando React 16.3 salió, teníamos una API de contexto completamente nueva. Cuando estaban experimentando para crear eso, también usaron la idea de los manejadores de efectos para construirlos. Pero nuevamente, problemas con la memoización y otras optimizaciones les impidieron lanzar eso con manejadores de efectos. Pero aún así, es realmente interesante comprobar esto.

Nuevamente, manejando efectos secundarios dentro de un componente. Así que esta es una propuesta de otro miembro del equipo central. Un ejemplo realmente similar. Y nuevamente, donde tienes el mismo patrón, pero en lugar de lanzar rayos, en lugar de atrapar, capturando efectos. Ahora, mi parte favorita sobre eso. ¿Quién aquí ha construido alguna vez una API lista para suspense? Así que estás construyendo un SDK, y quieres que la gente lo use con suspense. Oh. Así que te recomendaría que revises este, por ejemplo. Eso es React cache. Pero no tiene que ser React cache. Simplemente revisa cualquier API lista para suspense que uses. Por ejemplo, React fire o lo que sea. Verás el mismo patrón. Es decir, un componente es capaz de suspender la renderización lanzando una promesa, que es capturada y manejada por el framework. Y esto suena complicado, pero en realidad esta era la forma en que tenían que imitar los manejadores de efectos. ¿Y cómo? Porque tienes el mismo patrón de lanzar, manejar, reanudar, pero en forma de componentes de React.

Algunas conclusiones sobre eso. Así que supongo que la primera es, sí, React Fiber fue una reescritura de React, todo el núcleo de React, enfocado en dar más control para la ejecución a bajo nivel. Donde tenemos fibras como esta forma cooperativa de manejar la ejecución a bajo nivel, y tenemos efectos algebraicos como una forma de manejar efectos donde ellos y su comportamiento son independientes.

La segunda cosa que podemos ver es que React intenta mucho abordar la falta de esos recursos a nivel de lenguaje, porque JavaScript no los tiene, implementando soluciones alternativas cada vez que los revisamos, pensamos, está bien, esto suena como una solución improvisada o un atajo, pero no, es porque el lenguaje todavía está evolucionando, y carece de recursos, y esos son formas creativas de tenerlos. Por consecuencia, podemos ver que comprender esos internos y las razones detrás de ellos nos permite crear nuestras propias abstracciones. por ejemplo, el patrón de coincidencia o el programador 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, y en esta charla, él explica todo sobre por qué 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, me encanta este tweet. Es de hace años y años. Fue de Gisela Mahosh, y él 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 esos 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 Así que realmente me encanta eso. Y para mi última, tengo esta imagen. Y la gente dice que una imagen vale 1,000 palabras. Así que este soy yo hace ocho años en un meetup de iOS, diciéndoles a los desarrolladores de iOS que Ionic o Angular serían todo el futuro del desarrollo. Así que supongo que la última conclusión es no siempre confíes en todas mis especulaciones y predicciones futuras. Estas diapositivas estarán disponibles en mi perfil de Speaker Rack. Y eso es todo. Muchas gracias por estar aquí. Y se siente genial tener de vuelta estos eventos. Gracias. Muchas gracias. Ahora, antes de que la gente se apresure a almorzar, tengo esta enorme taza llena de monedas de React. Recuerden, si coleccionan la mayor cantidad de monedas de React, pueden obtener un premio. Quédense. Descubrirán cómo obtener estas de mí. Pero muchas gracias por su charla. Realmente la disfruté.

Realmente lo disfruté. Vamos a sumergirnos en algunas de esas preguntas. Entonces, al lanzar una promesa para suspense, ¿puedes también usar React hooks que almacenan datos en el fiber en los mismos marcos de pila? No estoy seguro si entiendo esta. Dice que la reformule, tal vez. Volveremos a esa. Pero saltemos a la siguiente pregunta sobre si try-catching es una operación costosa. Hasta donde sé, no. Para ser honesto, nunca he verificado como haciendo benchmarking sobre eso, para ser honesto, pero hasta donde sé, no. Probablemente esta pregunta fue por las cosas que mencioné. La dificultad de memorizar cosas y etc. Pero se relaciona más con la forma en que abstraes eso que con intentar y atrapar algo 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 lo mismo que era difícil optimizar eso, pero no por la naturaleza completa de intentar atrapar. Bien, bien.

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 hacer eso es hablando durante las discusiones con todos los IRFCs y lo que han estado haciendo desde el 18, un muy buen trabajo con los RFCs, etc., pero ve a través de los PRs, discusiones, especialmente las antiguas porque ves cómo evolucionaron hasta el punto en que están ahora. Entenderás el contexto, eso es una cosa, y revisa otros repos como React Basic y los repos de IRFCs. Hay repos 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 y implementa de manera nativa toda esta idea de manejadores de efectos. Se llama F. Observa cómo esos otros lenguajes abstraen sobre eso. Por ejemplo, para el tema de la homoiconicidad, Clojure u otros lenguajes Lisp. Así que, intenta ver cómo otros lenguajes que hicieron mucho trabajo previo sobre eso abstraen sobre esto y luego conecta con lo que ves del trabajo previo en el equipo de React e intenta unirlos todos.

Genial. Ahora, este siguiente parece más un comentario que una pregunta sobre Drupal lanzando valores en lugar de excepciones. Voy a suponer que no necesitamos sentirnos tan mal por React. Sí. No lo sabía para ser honesto. Quiero decir, he hecho PHP en el pasado pero no llegué a ese punto. Pero eso es interesante. Y por cierto, no estoy seguro si eso fue un post o solo un comentario en una discusión de PR pero luego Abramoff estaba mencionando que es una pena que hoy solo veamos suspense como lanzando promesas porque es mucho más que eso. Sé que hay mucho trabajo interesante sobre caching, por ejemplo, que se une con suspense. Así que yo mismo era uno que hacía bromas sobre lanzar promesas por un tiempo. Pero sí, es interesante ver eso. Genial. Muchas gracias.

Ahora, antes de que te vayas, amigos, tengo literalmente tal vez un par de cientos de monedas de React. Voy a dárselas a Matheus. Wow. Porque si vas a Matheus, puedes tomar algunas de estas monedas de React de él. Sin embargo, necesitas hacerle una pregunta. Así que Matheus, pueden hacerte una pregunta al azar, cualquier pregunta, te estoy lanzando bajo el autobús aquí. Podría ser sobre Fiber, podría ser solo sobre tu tiempo hablando. Y ve y habla con Matheus en el stand de preguntas y respuestas. Claro. Y míralo antes de ir a almorzar. No solo esto, pero no llegué a ponerlo en las diapositivas, pero intercambié stickers como un extra. Intercambia stickers, sí. Él y yo intercambiamos stickers en el stand. Definitivamente échale un vistazo para stickers geniales.