Así que simplemente ejecutamos, hay muchos efectos en ejecución, realmente, muchos efectos se están confirmando. Pero en algún momento lo que verás es que cambiamos los árboles del actual al trabajo en progreso. Y también llamamos a un hook. Cuando termina, ¿qué pasa? Eventualmente, marcamos la confirmación como detenida, y termina donde terminan todas las últimas cosas. Así que lo que quiero mostrarte con esto es, uno, cómo funciona con el bucle, pero también que hay muchos casos límite, hay muchas cosas que React resuelve por ti que no necesitas resolver tú mismo, y esa es toda la propuesta de valor, ¿cómo hacemos actualizaciones a la UI de una manera rápida, de una manera predecible, y de una manera que nos permite simplemente construir aplicaciones rápidas, sin preocuparnos demasiado con los internos. ¿Eso está bien? Muy bien. Hablemos de mi conclusión. ¿Qué podemos llevarnos de esta charla? Podemos llevarnos que los internos de React son complejos, pero los externos son poderosos debido a eso. Como, podemos construir todos esos casos límite, esos grandes switch cases que viste, nuestro trabajo que el equipo hace en nuestro nombre, para que no tengamos que hacerlo, para que React pueda tener un ambiente realmente bueno para construir aplicaciones de manera poderosa y rápida. Dicho esto, los internos son divertidos. Y mi única conclusión para ti es recordar, oye, escucha, React, he oído a mucha gente decir que React es demasiado difícil o demasiado complejo, como los internos. Toda esta charla que preparé fue leyendo el código fuente en GitHub porque es de código abierto y tratando de participar, y de hecho, ahora estoy participando, supongo, hablé con algunos del equipo que son muy acogedores y de apoyo, y es un ecosistema. Así que mi conclusión es, estoy agradecido de ser parte de este ecosistema y espero que te sientas alentado a hacerlo también. React Advanced London, gracias muchísimo por el tiempo. Gracias, gracias, gracias. Por favor, deja tu portátil y sígueme a la sala de interrogatorio. Uh-oh. Sí. Estoy a punto de ser interrogado. Estás en problemas, joven. No, gracias, eso fue una inmersión profunda. Realmente estás cumpliendo con tus promesas y el nombre de esta conferencia. ¿Soy un pez? ¿Eres un pez? ¿Quieres ser un pez? ¿Ser un pez es algo bueno? Hay un superhéroe en este show llamado The Boys que es un pez. The deep, de todos modos. Sí, yo, Aquaman está infravalorado es mi opinión. Esa es mi opinión. ¿Deberíamos hablar más de eso? No, está bien. Vamos a las preguntas de la audiencia. La primera pregunta de la audiencia es, ¿de qué manera has descubierto que una comprensión más profunda de React bajo el capó ha informado o cambiado el código que escribes? Me gusta mucho esto. Me gusta mucho esto. Así que en pequeñas formas. Y no puedo enfatizar lo suficiente cuán importante es no preocuparnos demasiado con los internos. Hay personas bien pagadas para hacer eso por nosotros, ¿verdad? Y así lo hacen bien por nosotros para que no tengamos que hacerlo, y el enfoque es usar React. Y ese es el enfoque. No necesariamente entender los internos. Pero entender los internos me ha ayudado en casos de revisiones de solicitudes de extracción donde tenemos debates o algo, podemos realmente mirar el código y puedo enseñar y mentorizar. Creo que ayuda. Pero también, me alejo de las micro-optimizaciones porque sé lo que está pasando. Como, no necesito poner todo en used memo. No necesito hacer todos mis componentes perezosos. Como, ayuda a informar cuánto optimizo porque sé cuánto se está optimizando para mí detrás de las escenas, así que. Por supuesto. Quiero añadir mi propia pregunta a eso. Recuerdo cuando solíamos trabajar con herramientas más sencillas que no eran tan poderosas, pero también eran más sencillas. En un momento, creo que recordaba la mayor parte del código fuente de backbone de memoria. Ahora con estas herramientas que usamos ahora, la complejidad es demasiado para un programador de producto en funcionamiento para mirar. Entonces, ¿cuánto crees que es importante a medida que te vuelves, digamos, más senior en la organización tener a una persona en el equipo que entienda estas herramientas? ¿O es simplemente una pérdida de tiempo? No sé si es una pérdida de tiempo, porque creo que una parte importante de ser un ingeniero senior es la capacidad de mentorizar. Hay una sala de habilidades blandas, ¿verdad? Realmente quiero asistir a eso porque siento que eso es en realidad más importante que el código en sí a veces. Y así creo que si hay al menos una persona que tiene un verdadero conocimiento profundo allí, pueden usarlo para educar e informar. Y hay muchos patrones en esta base de código de los que puedo aprender personalmente.
Comments