Lecciones para sobrevivir a React

Rate this content
Bookmark

Hubo un tiempo antes de React, y habrá vida después. Si te atas demasiado a cualquier tecnología, podrías atraparte y perderte la próxima ola. Ampliemos nuestra perspectiva más allá de la biblioteca de gestión de estado del momento: ¿qué lecciones atemporales podemos aprender de React? En la charla discutiré las lecciones que he aprendido al estudiar React y que llevaré conmigo durante el resto de mi carrera.

34 min
14 May, 2021

Video Summary and Transcription

La charla se centra en las lecciones que podemos aprender del éxito de React, incluyendo el diseño de API, la optimización para el cambio, las pruebas y la participación de la comunidad. La idea de una 'DX UX mullet', con el modo inmediato en el frente y el modo retenido en la parte posterior, se observa en diversas áreas del desarrollo de software. Se enfatiza la importancia de la nomenclatura y la optimización para el cambio, así como la relevancia de las DevTools y la construcción de una comunidad. También se discuten los principios detrás del marco Temporal y la importancia de una buena nomenclatura en el diseño de API.

Available in English

1. Lecciones para sobrevivir a React

Short description:

React es más antiguo que jQuery cuando se lanzó por primera vez. jQuery todavía impulsa una parte significativa de Internet, pero ya no es tan genial. React también enfrentará un destino similar. La charla se centra en las lecciones que podemos aprender del éxito de React. Las siete lecciones cubren el reconciliador, la superficie del API, el diseño del API, la optimización para el cambio, las pruebas, las herramientas de desarrollo y la comunidad. El patrón de reconciliador y programador de React es una buena idea para varios trabajos. El programador está viendo implicaciones más allá de React, y el equipo central de React lo ha dividido en su propio paquete. También están trabajando con el equipo de desarrollo de Chrome para potencialmente construirlo en el navegador.

Estoy aquí para ofrecer siete lecciones para sobrevivir a React. Entonces, la premisa de esta charla es que React es más antiguo que jQuery cuando se lanzó por primera vez. Y jQuery no está muerto. Todavía impulsa una gran cantidad de Internet, pero ya no es tan genial como solía ser. Y ese destino también llegará algún día para React. Debemos intentar pensar en lo que durará más allá de React.

Así que, mientras observamos a React en su ascenso y en su fase muy madura, deberíamos pensar en las lecciones que aprendemos de este enorme éxito. Hola, soy swix. Trabajo en muchas cosas diferentes. Y hago mucho en la comunidad de React. Pero principalmente doy charlas sobre React, lo cual es la calificación más relevante para esta conferencia. Y muchas de estas charlas se centran en elementos individuales de React. Pero esta es la primera charla que realmente cubre la filosofía general, de la cual creo que se pueden sacar conclusiones. Si quieres profundizar en detalles individuales, estas charlas son realmente buenas para cubrir los fundamentos técnicos de los cuales extraigo muchos de estos principios.

Así que las siete lecciones se presentan aquí de antemano. Hablaremos sobre el reconciliador, la superficie del API, el diseño del API, la optimización para el cambio, las pruebas, las herramientas de desarrollo y la comunidad. La primera parte es que el patrón de reconciliador y programador probablemente es una muy buena idea para varios trabajos. Y esto en realidad proviene de Jordan Walk, que es su idea original. Que sea lo que sea que produzca tu programa, píxeles, archivos, cualquier cosa, simplemente haz que tu programa regenere todo cada vez, agrega almacenamiento en caché y uso compartido estructural para que sea rápido y eso es todo. Y obviamente eso es gran parte de la presentación original, que capturé de la presentación original de JSConf. Y así es como React se diferenció desde el principio.

Pero tal vez también esté pasando por alto el otro MVP de React, que es la programación. ¿Correcto? Que es la otra parte. Y ahora estamos viendo mucha innovación, cuando cambias de React antiguo a React en modo concurrente, comienzas a obtener los beneficios de la división de tiempo, de lo que se habla mucho. Si quieres una introducción más detallada sobre la programación en React, definitivamente echa un vistazo al artículo de blog de Philips Spice, que presenté aquí. Este programador en realidad está comenzando a ver implicaciones más allá de React. Entonces, el equipo central de React en realidad separó el paquete del programador en su propio paquete con la esperanza de que otros frameworks puedan usarlo. Y están trabajando con el equipo de desarrollo de Chrome, eso debería ser del equipo de desarrollo de Chrome, para tal vez construirlo en su navegador. Entonces, si quieres React integrado en el navegador, esto es el comienzo.

2. DX UX Mullet: Modo Inmediato y Modo Retenido

Short description:

La idea de un DX UX mullet encapsula el concepto de modo inmediato en el frente y modo retenido en la parte posterior. El modo inmediato implica volver a renderizar todo el sistema cada vez, mientras que el modo retenido conserva el estado. Este patrón se observa en varias áreas como sistemas de compilación, GraphQL, tuberías ETL y Nullify, donde los desarrolladores buscan velocidad y simplicidad.

Pero en general, creo que esto encapsula la idea de un DX UX mullet. Ese es mi término para ello. Donde tienes el modo inmediato en el frente y el modo retenido en la parte posterior. El modo inmediato, simplemente vuelve a renderizar todo cada vez tanto para el frontend como para el usuario, así como para el desarrollador. Y el modo retenido, que es el sistema en el medio que realmente conserva el estado. Y esto es cierto para los sistemas de compilación. Jared Palmer está trabajando en un sistema de compilación donde tiene el mismo patrón exacto. Y comienza a ver este patrón una y otra vez en GraphQL, en tuberías ETL y Nullify. Y en muchos otros aspectos diferentes de la vida donde tienes un desarrollador trabajando con un sistema y quieres que sea rápido, pero también fácil de entender.

3. API Surface Area and Design

Short description:

La superficie mínima de la API es la segunda lección de la charla de Sebastian Markburger. Los patrones de biblioteca con demasiada API no son sostenibles. React ha reducido su propio formato de clase propietaria, colapsando las API con el tiempo. Sin embargo, este enfoque implica renunciar al enrutamiento, la gestión del estado y el estilo, que otros frameworks proporcionan. La tercera lección destaca que el diseño de la API es el diseño del lenguaje, con un enfoque en la nomenclatura y en cómo las personas hablan sobre React.

De acuerdo. Segunda lección. Superficie mínima de la API. Esta, por supuesto, proviene de la charla seminal de Sebastian Markburger donde expone esta filosofía. Básicamente, basado en su experiencia trabajando con Mood tools, dice que muchos patrones de biblioteca son simplemente demasiado grandes. Es simplemente demasiada API y no van a durar, y en realidad es difícil deshacerlo una vez que has creado esa API. Su solución es simplemente no intentarlo en primer lugar. Prefieres una API explícita y repetitiva en lugar de una implícita.

El compromiso, por supuesto, es que tendremos mucho más... Spoiler! Platos. Ves muchos ejemplos de cómo React crece con el tiempo. React ha eliminado voluntariamente su propio formato de clase propietaria para las clases ES6. Puedes ver que el diseño de React utiliza... Por ejemplo, con los hooks, donde puedes ver los hooks de terceros, como los hooks definidos por el usuario, están en el mismo nivel que los hooks principales de primera parte. Este concepto proviene de la charla de Guy Steele `Growing a Language`, que recomiendo encarecidamente. Puedes ver que React intenta colapsar las API. Tienen estas tres API de clases de componentes muy comunes y las colapsan en GDSFP, y luego también escriben una publicación de blog para recordarte que es posible que no lo necesites, especialmente si usas funciones. Así que cada vez menos API con el tiempo, y realmente aprecio al equipo central de React por eso. Pero hay un costo, que es que renuncias... No hay una solución de enrutamiento, no hay una solución de gestión del estado, no hay estilos, y todo eso viene con React. Y esto es algo que otros frameworks dan por sentado y con lo que los desarrolladores de React luchan. Así que hay un costo en eso. Comentaremos sobre eso en una lección futura.

Pero la tercera lección es que el diseño de la API es el diseño del lenguaje. Y esto es muy similar al punto anterior, pero distinto. Y el punto en esto, y el énfasis aquí está en la nomenclatura y en la forma en que las personas hablan sobre React. Lee Byron tuvo una gran contribución en esto, incluso antes de cofundar GraphQL. Al sentarse y definir los conceptos, las acciones, los operandos y las notificaciones, puedes ver el resultado de eso en las elecciones de diseño de la API de React. Y estas son las que conocemos. Pero han cambiado mucho con el tiempo.

4. Naming, Hooks, and Optimizing for Change

Short description:

La nomenclatura ayuda a dar forma a nuestro pensamiento en React. Los hooks proporcionan una sintaxis de nomenclatura común y una API de una sílaba para los humanos. El principio de UI antes que API y la disposición a permitir a los usuarios modificar las soluciones existentes. La lucha con los componentes envolventes y la pirámide del caos. Intentos de solucionar el problema con componentes de orden superior, props de renderizado y el componente React.headless. La realización de que los hooks son una mejor opción. Lección número cuatro: optimizar el diseño de la API para el cambio.

Pero aún hay una gramática que se ha establecido que podemos esperar y recomendar. Y tiene sentido para nosotros como desarrolladores de React. Nos ayuda a pensar en React basándonos en el lenguaje. Y eso es una parte muy importante de esta hipótesis de valor aparente, que es que la nomenclatura en realidad ayuda a dar forma a nuestro pensamiento. Las palabras que usamos ayudan a dar forma a nuestro pensamiento.

También puedes ver esto en los hooks. La forma en que se usa `use` es una sintaxis de nomenclatura muy común para los hooks. O una sintaxis de nomenclatura recomendada para los hooks. Y solo el nombre de los hooks en sí. Estos son los otros 50 nombres que se consideraron para los hooks antes de decidirse por hooks. Y en parte, se considera que sí, quieres algo que sea una sílaba, para poder referirte a él en conversaciones diarias. Pero también es una API que los humanos usan en lugar de las computadoras. Y en general, creo que tal vez Dan lo expresó mejor. Él dice UI antes que API. Quieres comenzar con el resultado final y luego trabajar hacia atrás para crear las APIs que te ayuden a llegar allí. Pero su otro principio también es muy interesante. Hacks y luego idiomas. Lo que significa que está dispuesto a permitir que los usuarios hagan trucos con lo que tienes, en lugar de construir una API adicional solo para acomodarlos.

Y aquí, es muy claro lo que es, si eres de una cierta generación en React, donde tienes muchos componentes envolventes solo para inyectar algo con redux o GraphQL. Y esta pirámide del caos, me encanta agregar un poco de Hadoop allí, solo para simbolizar cuán profundo realmente es. Hay muchas soluciones que intentan resolver esto. Hay muchas soluciones que resultan en esto, y simplemente no tienes otra opción porque React realmente no te dio otra forma. Entonces, si querías inyectar estado, necesitabas un componente de orden superior. Hubo una breve revolución para los props de renderizado, nuevamente de las mismas personas que recomendaban los componentes de orden superior. Intentaba resolver esta gran pirámide del caos, introduje un RFC de React llamado componente React.headless. Y todos estos eran solo formas de inyectar comportamiento, que realmente no eran correctas. Y todos nos dimos cuenta de que los hooks eran simplemente una opción mucho mejor al final.

La lección número cuatro es optimizar para el cambio. Entonces, este es el punto final sobre el diseño de la API, que no debes optimizar para, ya sabes, no repetirte a ti mismo, o no debes optimizar para tener menos líneas de código. Optimiza para el cambio, y aquí está el por qué.

5. First-Order Design and Optimizing for Change

Short description:

El diseño de primer orden es que tu código debe ser fácil de leer y escribir. Quieres que lo correcto sea lo fácil. Una vez que hayas escrito algo, los requisitos comienzan a cambiar. Una gran API no solo te permite caer en un pozo de éxito, sino que también te ayuda a permanecer allí. La solución del equipo de React es permitir el razonamiento local para optimizar el cambio. Optimizar para el cambio es una idea fundamentalmente importante que durará más que React. Lección número cinco: prueba la API pública.

Entonces, el diseño de primer orden es que tu código debe ser fácil de leer y escribir. Debes tener todas estas características. Me gusta mucho la idea del pozo de éxito. Es bastante común afirmar que quieres que lo correcto sea lo fácil. Quieres ser memorable, como Lee Byron creando la gramática para React. Eso es muy memorable. Necesitas ser adivinable. Ese es un buen consejo de Jon O'tander. Y también quieres fomentar el rendimiento, la accesibilidad, la seguridad y la experiencia del usuario. Todos estos son igualmente importantes. No hagas juicios de valor sobre cuál es más importante. Pero una vez que hayas escrito algo, los requisitos comienzan a cambiar. Y ahí es donde entra el diseño de segundo orden. También quieres que sea fácil de cambiar. Entonces, si tienes un código muy frágil, un ligero cambio en los requisitos hará que tu código se desmorone. Por lo tanto, una gran API en realidad anticipa que quieras cambiar el nombre o copiar y pegar, unificar en una abstracción o dividir en abstracciones, eliminar o agregar un truco. Hacer todo tipo de cosas en tu código, y no debe desmoronarse cuando intentes hacer eso. Entonces, una gran API no solo te permite caer en un pozo de éxito, sino que también te ayuda a permanecer allí. Y esa es una observación realmente muy buena. Y eso es algo que se ve mucho en otros formatos. Por lo tanto, dos referencias a las que me gustaría señalarte si quieres investigar más sobre esto, son el blog de Stack Overflow, donde lo llaman volatilidad de requisitos, así como Hillel Wain, quien lo llama perturbaciones de requisitos. La misma idea, diferentes enfoques. La solución del equipo de React para resolver esto es permitir el razonamiento local, tratar de reducir la cantidad de contexto global que necesitas, y simplemente enfocarte en el código que tienes frente a ti, y eso debería permitirte cambiar lo que necesites. Porque entonces en realidad no tienes que tener una acción espeluznante a distancia. Esto se ve en las publicaciones de blog de Dan, en Sophie Alpert hablando sobre Data Loader. Puedes ver esto en Style Components, Tailwind o el diseño del compilador de Relay. Hay muchas formas diferentes en las que puedes permitir el razonamiento local que ayuda a optimizar el cambio de las cosas.

6. Testing, DevTools, and Building

Short description:

Tengo muchas más diapositivas que estas. Tuve que recortar porque no tengo tiempo, pero no dudes en contactarme porque optimizar para el cambio es una idea fundamentalmente importante que durará mucho más que React. Lección número cinco: prueba la API pública. Muy, muy simple. Debes escribir pruebas, no muchas, principalmente de integración. No pruebes los detalles de implementación. Lección número seis: las DevTools no son opcionales. React enfatiza las DevTools. React también utiliza Codemods. Las advertencias de desarrollo de React es algo que se lleva al límite con React. No puedes automatizar todo, así que es bueno introducir algunas soluciones. El último consejo es un meta-consejo: DevTools para ayudarte a construir DevTools. Debemos ser conscientes de lo que estamos construyendo y enviando y debemos ser conscientes de las grandes regresiones.

Tengo muchas más diapositivas que estas. Tuve que recortar porque no tengo tiempo, pero no dudes en contactarme porque optimizar para el cambio es una idea fundamentalmente importante que durará mucho más que React.

Lección número cinco, prueba la API pública. Muy, muy simple. Debes escribir pruebas, no muchas, principalmente de integración. No pruebes los detalles de implementación. Esto es obviamente muy, muy importante para React porque React emprendió una gran reescritura de todo el código base, pero mantuvo las pruebas y las pruebas realmente sobrevivieron al código base, y eso no es algo muy perspicaz para tus aplicaciones. Obviamente, también implementaron esta pequeña cosa de seguimiento para IsFiberReadyYet, donde realmente rastrearon la finalización hacia la reescritura. Y es algo realmente motivador de ver para el código base de React, que en realidad se ha extendido como un movimiento hacia las aplicaciones de React, ¿verdad? Hemos visto que Enzyme ha disminuido relativamente en comparación con la React Testing Library, y eso es como debería ser, porque nuestra React Testing Library se enfoca en probar solo la API pública de los componentes. Y eso es lo que usarán tus usuarios, y eso es lo único en lo que realmente debes preocuparte en tus pruebas. Y esto lo hace mucho menos frágil en comparación con lo que había antes.

Lección número seis. Pasamos a las DevTools. Las DevTools no son opcionales, y puedes ver cuánto enfatiza React en las DevTools. Por supuesto, las DevTools oficiales de React, el complemento de Chrome, es mantenido por Brian Vaughan en el equipo central de React, y hace un trabajo increíble. No sé cuánto pagaría por esto, pero pagaría por esto. Y debes aprender todas las complejidades si quieres depurar. React también utiliza Codemods. Esto no es opcional para React básicamente porque el equipo de React realmente tiene que mantener las decenas de miles de componentes que están en el código base de Facebook, y tienes que actualizar todos ellos cada vez que cambian las APIs, así que por supuesto tienes que automatizar estas cosas. Y nosotros, como comunidad de React, nos beneficiamos. Las Advertencias de Desarrollo de React es algo que se lleva al límite con React. Por lo tanto, puedes ver la superposición de errores de React, o puedes ver las advertencias de lint, o puedes verlo en la consola. Incluso tenemos códigos de error, por lo que puedes ver errores agradables en producción, pero sin tener un peso adicional en los artefactos de compilación finales, y es una experiencia de decodificador muy agradable, que desearía que más herramientas para desarrolladores copiaran. No puedes automatizar todo, así que es bueno introducir algunas soluciones. Realmente me gusta esto como una forma de aprender React también, porque puedes comenzar a activar banderas de funciones y cambiar diferentes navegadores y ver cómo cambia el comportamiento. Es una forma realmente agradable de probar manualmente las cosas teniendo todo en su lugar para que no pierdas tiempo configurándolo. Y finalmente, el último consejo es como un meta-consejo. DevTools para ayudarte a construir DevTools. Para React, porque está construyendo una biblioteca que se integrará en millones de otras aplicaciones, necesitan mantener el tamaño del paquete pequeño y no aumentarlo involuntariamente, y es algo que realmente podemos tomar prestado para nuestras aplicaciones también. Debemos ser conscientes de lo que estamos construyendo y enviando y debemos ser conscientes de las grandes regresiones.

7. Importance of Community Engagement

Short description:

Las DevTools no son opcionales. Construir una comunidad es crucial. El equipo central inicial de React escuchó los comentarios y se involucró con la comunidad, lo cual dio sus frutos al atraer a más usuarios. Debemos aprender de esto y priorizar la participación de la comunidad en nuestros propios proyectos.

Entonces, las DevTools no son opcionales. La última lección es que no debemos descuidar la comunidad. También queremos construir una comunidad. Esto obviamente se remonta al comienzo de la liberación de código abierto de React. De hecho, Jordan Walk tuvo que introducir JSX porque estaba siendo ignorado internamente en Facebook. Y una vez que introdujo JSX, realmente les gustó mucho más. Pero luego, ocurrió lo contrario cuando lo hicieron de código abierto al público. Aquí tenemos a Jordan en medio de los focos tratando de introducir JSX con una recepción muy negativa, y aquí está Pete Hunt tratando de rescatarlo diciendo: `Oye, es opcional, chicos, no se preocupen tanto`. Y creo que eventualmente nos convencieron de la idea. Pero lo importante es que todo el equipo central inicial realmente escuchó los comentarios. Estaban en IRC y Stackoverflow las 24 horas del día, los 7 días de la semana, y respondían a cada crítica considerándolas como su propia responsabilidad. Y ese trabajo en la comunidad dio sus frutos. Comenzaron a atraer a muchos usuarios, en particular David Nolan de la comunidad de ClojureScript que construyó Omen, realmente comenzó a generar mucho entusiasmo por React. Y creo que eso es mucho trabajo previo que tal vez se haya olvidado con el tiempo. Pero creo que si estamos comenzando a crear nuestros propios proyectos que queremos que sean tan populares como React, necesitamos comenzar a prestar atención a la comunidad tal como ellos lo hicieron. Y esa es una lección que llevamos con nosotros.

8. Distribución y Lecciones de React

Short description:

La distribución de React ha llevado a una disminución en la destrucción creativa de los frameworks. El enfoque de React ha pasado de centrarse en características a la estabilidad. Las siete lecciones cubiertas en esta charla incluyen tener una idea central, trabajar en el diseño de la API, producirlo y humanizarlo. La lección principal es enamorarse de los problemas porque las soluciones van y vienen, pero los problemas permanecen. Consulta el libro en learningpublic.org para obtener más principios.

Además, debemos comenzar a resolver puntos problemáticos. Entonces, uno de los grandes puntos problemáticos fue que React es tan pequeño que no resuelve el resto de las otras aplicaciones y la gente comenzó a hacer memes y bromas al respecto. Así que, Dan Abramov realmente creó Create React App. Y esa es una historia que cuento en una charla separada llamada Create React App.

Pero en general, la historia de esto es básicamente una distribución de React, ¿verdad? Agrupas React con otras cosas, Next.js y Gatsby lo agrupan con enrutamiento y Blitz y Redwood agrupan Next.js y así sucesivamente. Puedes agrupar y agrupar y agrupar. Y lo que realmente estamos viendo aquí es una disminución en la destrucción creativa de los frameworks y la madurez y despliegue de React y estamos comenzando a construir sobre React en lugar de tratar de competir con React. Y lo principal que React, el contrato de React comienza a cambiar, ¿verdad? Ahora lo principal que cambia en React, no son las características. Es la estabilidad. Por supuesto, la curva S no es un final. Puede comenzar a ser una S nuevamente cuando React esté completamente fuera.

Entonces, las siete lecciones que cubrimos son todas estas. Creo que será un poco difícil de recordar si tienes siete años. Sabes, la memoria de trabajo es solo de tres a cinco. Así que aquí está mi desglose. Primero, tienes una idea central de lo que tu biblioteca o framework va a hacer. Luego quieres trabajar en la interfaz entre el desarrollador y tu biblioteca central. Eso es el diseño de tu API. Luego quieres producirlo, ya sabes, trabajando en las pruebas, trabajando en las herramientas de desarrollo. Y finalmente, quieres humanizarlo para asegurarte de encontrarte con las personas donde están. Y esas son las siete lecciones. No son las únicas siete lecciones que se pueden aprender de React. Y hay más en camino. El equipo de React es muy generoso al compartir sus lecciones sobre React concurrente. Así que debes prestar atención a eso. Pero en general, la lección principal que quiero dejarte es que te enamores de los problemas porque las soluciones van y vienen, pero los problemas siempre permanecerán. Eso es todo. Si quieres aprender más sobre estos principios, que creo que durarán toda nuestra carrera, debes consultar mi libro en learningpublic.org. De lo contrario, muchas gracias por recibirme y nos vemos en el resto de las charlas. Adiós.

QnA

API Surface Area and Optimization

Short description:

La mayoría de las personas dicen que se debe tener un área de superficie de API mínima y optimizar para el cambio. El orador comparte su rol actual en temporal.io, una startup de orquestación de microservicios en el backend. Explica su motivación para unirse a una empresa pequeña en una etapa temprana. El orador también menciona una pregunta de Juan Segebre sobre los obstáculos comunes y las mentalidades que dificultan la optimización para el cambio.

Parece que la mayoría de las personas dicen que se debe tener un área de superficie de API mínima y optimizar para el cambio. Tenemos muchos empates en esto, como 36%, 36%. Así que dividido por la mitad, ¿eso era lo que esperabas de esta pregunta? ¿El área de superficie de la API? Creo que sí. Creo que se ajusta muy bien a lo que la gente responde. Sí. Genial. Increíble.

Bueno, tenemos muchas preguntas para ti, pero quería comenzar con una. Y esa es, ¿qué estás haciendo ahora? Así que en tu presentación, pensé, eras un defensor principal del desarrollador para AWS, pero sé que has seguido adelante porque ese es el equipo en el que estoy. ¿Entonces qué pasa? ¿Qué estás haciendo ahora? Oh, te pusieron a cargo y tuve que irme. Es una broma, todos. Se fue antes de que yo me convirtiera en el gerente. No. Sí, claro. No, en serio. De todos modos, sí, acabo de unirme a temporal.io. Es una startup de orquestación de microservicios en el backend. Muy, muy diferente a lo que normalmente hago. Y quería, supongo, ampliar mis horizontes. Pero también apostar por una empresa pequeña. Sabes, están en la Serie A, en una etapa muy temprana y esperando ser la próxima gran startup de orquestación en el backend. Y si alguna vez has trabajado en tareas de larga duración, como sagas para el backend, esto es algo que realmente deberías revisar. Pero no voy a promocionarlo en una conferencia de React. Así que tuve que preparar una charla diferente para esta ocasión. No, eso es genial. Es realmente genial. También tenemos más preguntas. Esta es de Juan Segebre. ¿Cuáles son los obstáculos comunes y las mentalidades que nos impiden optimizar para el cambio? ¿Que nos impiden? Lo siento. Supongo que es ¿qué nos ayuda a optimizar para el cambio? ¿O qué nos hace evitar el cambio? Uno de los dos.

Optimizando para el Cambio y Escribiendo Publicaciones de Blog

Short description:

Existen varias formas de optimizar para el cambio en el desarrollo de software. Un enfoque es evitar depender del orden de los argumentos y en su lugar utilizar objetos de opciones. Otra estrategia es colocar los datos en el mismo lugar y facilitar su eliminación, ya que el código de solo agregado puede generar deuda técnica. El orador planea escribir un artículo más detallado sobre este tema en el futuro. También se discute la importancia de seguir la regla de las tres oportunidades al escribir publicaciones de blog, encontrando un equilibrio entre publicar demasiado y publicar muy poco.

Porque se supone que eso es bueno. No estamos tratando de evitarlo. Espera. Estoy pegando mis diapositivas y mis enlaces en Discord. Ahí es donde los tengo. Y no sé si hay otros canales donde debería publicarlo. Pero si alguien quiere seguir todas los recursos que pegué, pueden hacerlo ahí.

Pero, sí, en esencia hay mucho, ¿verdad? Creo que simplemente pensar en tu design pensando en los cambios que podrían llegar y arruinar tu día es básicamente la idea. Y puede ser algo tan pequeño como depender del orden de los argumentos. Por ejemplo, si observas en React, las props realmente no se preocupan por el orden de los argumentos. Y eso se debe a que básicamente es un objeto de opciones. Lo cual es algo que, si ves una de mis charlas favoritas, Simple Made Easy de Rich Hickey, depender del orden de algo en realidad es complejidad. En realidad, te hace tener que recordar, como, ¿qué viene después de qué? Mientras que si pones las cosas en un orden independiente, te liberas. Pero también puede ser algo tan grande como ¿estás colocando data en el mismo lugar y haciendo que sea fácil de eliminar? ¿Verdad? Porque el código de solo agregado es una fuente importante de deuda técnica. Si tienes miedo de eliminar cosas porque no sabes qué efectos globales va a tener, entonces básicamente tienes lo que yo llamo momificación de tentáculos. Porque simplemente estás poniendo una venda tras otra y terminas con una momia de deuda técnica. Y sí, hay muchas formas de optimizar para el cambio y planeo escribir un artículo más extenso sobre esto en el futuro, pero quería mencionarlo aquí.

Eso es increíble. Y definitivamente las personas deberían seguirte en las redes sociales para ver todas tus publicaciones de blog porque es impresionante cómo escribes sobre las cosas. Y publicas artículos y ves un tema un par de veces y escribes sobre ello. Y eso es genial. Sí, lo llamo la regla de las tres oportunidades. Creo que las personas tienen una barrera sobre cuándo deberían escribir sobre algo porque sienten que necesitan ser expertos en ello para escribir al respecto. O tienen lo contrario completo. Publican cada pensamiento que tienen. Y esos dos extremos no son muy ideales, ¿verdad? Porque o publicas demasiado o publicas muy poco. Entonces, mi regla de las tres oportunidades es que una vez que has mencionado una idea tres veces, deberías intentar escribir un blog al respecto. Porque eso ha perdurado el tiempo suficiente como para demostrar que probablemente se mantendrá un poco más en tu mente. Pero no es demasiado tiempo como para que te hayas aburrido de ello.

Presión de Blogging y Nuevos Frameworks

Short description:

Para reducir la presión con tu blogging, simplemente publícalo después de tres intentos. Encuentra un medio diferente donde puedas experimentar más. Utiliza diferentes medios para diferentes propósitos. Considera la idea de un jardín digital. Svelte es un framework que podría reemplazar a React en el futuro. El éxito de React ha inspirado a otros. Temporal está implementando estas ideas.

la idea o está empezando a perder relevancia. Así que estoy tratando de promover este concepto de que para reducir la presión con tu blogging y simplemente publícalo después de tres intentos. Me encanta esa idea. Soy tan perfeccionista que me resulta muy difícil realmente presionar publicar en cualquier cosa, tomo notas de todo. Pero eso es un gran punto.

Eres un escritor muy pulido. Y creo que eso es algo que tenemos que entender como creadores de contenido. Tu blog transmite una expectativa sobre la cantidad de trabajo que se le dedica. Y ahora, creo que si te desvías de eso, las personas se sentirían un poco... incómodas con eso. Así que creo que necesitas encontrar un medio diferente donde puedas experimentar más y donde las personas no esperen ese nivel de pulido. Así que soy partidario de utilizar diferentes medios para diferentes propósitos. Oh, me encanta eso. Me encanta eso. Me estás dando todos los consejos aquí. También me encanta la idea del jardín digital. A la gente parece gustarle mucho eso especialmente en la comunidad de egghead. Así que debería adentrarme más en eso. Ya has publicado todos tus recursos, lo cual es increíble. Esa era nuestra siguiente pregunta. Luego la siguiente es de Sasha. ¿Hay algún framework específico nuevo y mejorado basado en estas lecciones en el que preveas que podría reemplazar a React en el futuro? Wow. No quería llegar a eso, pero realmente me gusta Svelte. Estamos organizando una conferencia en dos semanas. Así que puedes venir a ver el Svelte Summit. Está en YouTube. Creo que es algo general para el código abierto. Si estás trabajando en marketing de desarrollo o comenzando un proyecto de código abierto o quieres apostar temprano por el código abierto, estas son las cosas a tener en cuenta. Estas siete lecciones no son las únicas lecciones y estoy interesado en que otras personas entiendan lo que pueden aprender de React. React es uno de los frameworks de código abierto más exitosos del mundo. Todos están interesados en replicarlo.

Temporal Framework and Learning Principles

Short description:

Temporal es un framework de código abierto que surgió de Uber. Es útil genéricamente y se puede aplicar a diversas áreas. Los principios detrás del framework son más importantes que la API específica. Aprender y aplicar estos principios tendrá un impacto duradero en tu carrera.

éxito para su propia cosa. Mi empresa, estamos implementando estas ideas en Temporal. Temporal es un framework de código abierto que surgió de Uber y estamos tratando de comercializar y popularizarlo. Creo que es útil genéricamente, la única observación específica del front-end fue la primera, que se trata más de la conciliación y la programación, que es algo muy enfocado en el front-end. Pero luego te das cuenta de que puedes aplicarlo a otras cosas. Yo presenté un tweet de Jared Palmer diciendo que está utilizando las mismas ideas exactas para el sistema de compilación. Y eso no tiene nada que ver con el DOM o el front-end, pero eso es genial. Son los mismos principios de ingeniería de software que puedes reutilizar una y otra vez. Y creo que ese es mi punto final, que cualquier cosa que aprendas, no estás aprendiendo la API. Puedes aprender la API, pero realmente lo que se quedará contigo incluso después de que ese framework desaparezca son los principios. Y deberíamos tratar de aprender de eso porque eso se acumulará y durará toda nuestra vida.

HyperApp and Naming Systems

Short description:

¿Has probado HyperApp? Es un framework ligero que refleja la arquitectura de Elm. Encuentro difícil usar el lenguaje de programación Elm. ¿Cómo se crea un buen sistema de nombres? Tengo una publicación en mi blog sobre ese tema. Es importante tener una perspectiva sobre la nomenclatura y no rendirse antes de intentarlo. Tu primer usuario de blog eres tú mismo.

Entonces, realmente, realmente valioso de aprender. Eso es increíble. Eso es genial. ¿Has probado alguno de los otros nuevos frameworks de los que hablaste, pero has probado HyperApp por casualidad? No, ¿qué es? Es un framework súper ligero que te permite usar JSX también, pero refleja la arquitectura de Elm, que realmente disfruté. ¿Conoces Elm, en el front-end? Sí. De hecho, he leído la tesis de graduación de Evan Czeplicki, que es la base de Elm.

Eso es increíble. Y es la tesis de pregrado más impactante. No recuerdo mi propia tesis de pregrado. Yo recuerdo la mía. Escribí muchos tweets y todo se trataba de cómo la gente discute diferentes políticos en las redes sociales, pero sí, es un insight súper interesante, pero sí, HyperApp. Está escrito en JavaScript, pero tiene la arquitectura de Elm. Me gusta mucho porque es ligero. Me gusta la arquitectura de Elm, pero encuentro el lenguaje de programación un poco difícil de usar, así que no sé. Es interesante.

Esta pregunta es de Katre. ¿Cómo se crea un buen sistema de nombres cuando no es tu punto fuerte? ¿Cuánto tiempo se debe dedicar a eso? Tengo una publicación en mi blog sobre cómo nombrar las cosas. De hecho, he intentado responder a esta pregunta porque es uno de los problemas difíciles conocidos. Debemos tener una perspectiva sobre la nomenclatura. Si dices que no eres bueno en eso y no lo intentas, entonces básicamente te estás rindiendo antes de empezar. No creo que esa sea una forma muy productiva de manejar las cosas porque tendrás que nombrar cosas. Eso es gran parte de lo que hacemos como coders. No sé. ¿Cuál era la pregunta de nuevo? ¿La respondí? Muchas de mis respuestas son como tengo una publicación en mi blog sobre eso. Y es una buena forma de vivir porque es una buena forma de aprovechar el tiempo, ya que paso horas en eso. No lo voy a dar en este pequeño chat. Si a la gente le interesa de verdad, pueden buscarlo. Sí. Es casi como una filtración de tu segundo cerebro. No tienes que recordar todas estas cosas porque

Importancia de la Nomenclatura en el Diseño de API

Short description:

El equipo de React pone mucho esfuerzo en la nomenclatura porque es crucial para la comunicación humana. Un buen diseño de API implica considerar cuidadosamente la nomenclatura. El equipo de React consideró varios nombres antes de decidirse por hooks, que es un nombre simple y efectivo.

has escrito sobre ellos en el pasado. Tu primer usuario de blog eres tú mismo. Entonces, la pregunta era sobre cómo crear un buen sistema de nombres y cuánto tiempo se debe dedicar a ello, a lo que creo que respondiste. Sí. Quiero decir, estoy realmente inspirado por cómo el equipo de React piensa tanto en la nomenclatura. Y eso no significa nada para la computadora, pero lo es todo en cuanto a la comunicación entre humanos. Eso es gran parte de lo que implica un buen diseño de API. Y cuando ves, publiqué una captura de pantalla en mis diapositivas de la cantidad de nombres que consideraron antes de decidirse por hooks. No es una coincidencia que sea un nombre tan simple y de una sola sílaba que a muchas personas les resulta problemático.

Naming and Optimizing for Change

Short description:

De acuerdo. Tuve algunos problemas con eso, pero fue lo suficientemente bueno. Transmitió el mensaje y fue útil. Eso es lo que están buscando y eso es algo que creo que, con algo de práctica, al menos puedes evitar nombres malos. Lo cual es bueno. No sé cómo nombrar las cosas. Eso es difícil. Entonces, volviendo a esa primera pregunta, cambian su terminología. Entonces, queremos optimizar para el cambio, ¿qué cosas nos impiden hacer esto? ¿Qué conceptos erróneos? De esa manera, podemos tratar de alejarnos de ellos. Creo que esto se relaciona con el diseño de API y el acoplamiento y cómo cuando tomas ciertas decisiones. Hay una tabla de opciones fundamentales de diseño de API que conducen a un diseño simple y a un diseño más complejo. Y creo que es la pura verdad que si simplemente evitas las opciones más complejas, eso ayuda a comprender qué te lleva a optimizar para el cambio. Honestamente, hay mucha verdad en el hecho de que te estás basando en el orden. Y el orden puede significar un orden jerárquico así como un orden secuencial.

el nombre hooks. De acuerdo. Tuve algunos problemas con eso, pero fue lo suficientemente bueno. Transmitió el mensaje y fue útil. Eso es lo que están buscando y eso es algo que creo que, con algo de práctica, al menos puedes evitar nombres malos. Lo cual es bueno. Y creo que probablemente el primer paso es evitar múltiples nombres para el mismo concepto muy diferente. Y también puedes comprender qué es la abstracción más genérica que estás tratando de nombrar. No sé cómo nombrar las cosas. Eso es difícil. Sí, definitivamente es un problema sin resolver. De acuerdo. Entonces, volviendo a esa primera pregunta, cambian su terminología. Entonces, queremos optimizar para el cambio, ¿qué cosas nos impiden hacer esto? ¿Qué conceptos erróneos? De esa manera, podemos tratar de alejarnos de ellos. Oh, gracias. Entendido. ¿Qué podría impedirnos hacer esto? ¿Qué conceptos erróneos? Ah, interesante. Realmente no lo había pensado. No sé. No sé si hay algo como hacer lo contrario a todo lo que recomendé. Sí. Creo que esto se relaciona con el diseño de API y el acoplamiento y cómo cuando tomas ciertas decisiones. Entonces, gran parte de esto se encuentra en la charla de `simple made easy` porque en realidad tiene una tabla. Tuve que eliminar esto de mi charla debido al tiempo. Pero hay una tabla de opciones fundamentales de diseño de API que conducen a un diseño simple y a un diseño más complejo. Y creo que es la pura verdad que si simplemente evitas las opciones más complejas, eso ayuda a comprender qué te lleva a optimizar para el cambio. Honestamente, hay mucha verdad en el hecho de que te estás basando en el orden. Y el orden puede significar un orden jerárquico así como un orden secuencial.

Optimizando para el Cambio y Estilos Localizados

Short description:

Hacer que tu asincronía, obtención de datos, renderizado y estilos sean independientes del orden permite un razonamiento local y optimizado para el cambio. Si bien evitar las variables globales es ideal, su uso limitado puede ser aceptable. Los cambios localizados en elementos específicos, como con tailwind, ofrecen un enfoque más localizado para los estilos. La capacidad de tailwind para aplicar estilos directamente a los elementos es una tecnología fascinante que merece una mayor exploración.

algún tipo de orden secuencial. Y creo que una vez que haces que tu asincronía, tu obtención de datos, tu renderizado, tus estilos, sean independientes del orden, entonces permites, entonces habilitas un razonamiento local. Y eso es en última instancia lo que el equipo de Facebook y en última instancia algo con lo que estoy de acuerdo, en última instancia, creen que ayuda a optimizar para el cambio. Evitar las variables globales es una de esas respuestas muy sencillas. Pero a veces las variables globales son realmente útiles. No sé cómo me siento acerca de las variables globales. Creo que el uso limitado de variables globales es probablemente la forma correcta de expresarlo. Y luego todo lo demás, ya sabes, simplemente trata de hacer, trata de mantener las cosas localizadas en la localidad donde las cambias, lo cual, por cierto, es una de las razones por las que realmente me gusta tailwind, porque tailwind aplica estilos directamente al elemento, como si estuvieras usando estilos en línea. Esa es una tecnología fascinante, que espero que más personas estén explorando.

Consejos de Carrera para Desarrolladores

Short description:

Quiero centrarme en tu libro en lugar de en tu charla. Tres consejos favoritos de carrera: conocimiento de código abierto, lo suficientemente bueno es mejor que lo mejor, aprovecha lo que te ofrecen.

¡Eso es genial! ¡Eso es genial! De acuerdo. Tenemos aproximadamente un minuto. Quiero centrarme en tu libro en lugar de en tu charla. ¿Cuáles son tus tres consejos favoritos de carrera para un desarrollador junior a senior? Todavía estoy aquí al margen. Oh, Dios mío. Por lo que vale, tengo 40 capítulos. Me estás pidiendo que elija mi favorito entre todos. Esto va a ser difícil. De acuerdo. Permíteme intentar hablar sobre, así que creo que una cosa es tener conocimiento de código abierto, básicamente. De hecho, tengo una charla sobre esto en mi canal de YouTube donde es una variante de lo que se me conoce, que se llama aprender en público. Pero esto realmente implica exponer tus materiales en público y permitir que las personas contribuyan y lo vayan evolucionando con el tiempo. Mientras que muchas personas, cuando intentan aprender en público, tienden a crear artículos terminados como un video de YouTube, una publicación de blog. Eso es más bien algo de una sola vez tipo de cosa. Quiero que las personas intenten construir más cosas con el tiempo y simplemente vayan y construyan algo sustancial y útil para ellos mismos y para todos los demás a su alrededor. Así es como me involucré en la construcción del proyecto de hojas de referencia de React y TypeScript. Eso es compartir tu conocimiento de código abierto. Otro que me gusta mucho es la idea de que lo suficientemente bueno es mejor que lo mejor. Deja de buscar lo mejor porque nunca estarás satisfecho. Tienes que estar al tanto de los anuncios de noticias de otras personas y tienes que preocuparte por lo que otras personas piensan y enfocarte en lo que es lo suficientemente bueno, en lo que necesitas y en lo que conoces mejor. Finalmente, supongo que uno más que quiero mencionar es aprovecha lo que te ofrecen. Así que si quieres, muchas personas preguntan sobre cómo empezar, cómo comenzar a escribir y aprender en público. Y descubren que no tienen tracción ni lectores. Responde al trabajo de otras personas. Si acabo de publicar un nuevo libro, revísalo o interactúa con los creadores y verás que tendrás muchas más posibilidades de recibir una respuesta y convertirte en colaborador y eventualmente en amigo. Esos son mis tres consejos.

Eso es increíble. Son excelentes consejos. Muchas gracias. Ha sido divertido ponerme al día y también genial escuchar tus consejos y tu charla. Increíble. Sí. Muchas gracias por recibirme y nos vemos en el chat.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn