Visualizando React: Metáforas, Modelos y Medios Espaciales

Rate this content
Bookmark

Todo el React que has visto se presenta de una manera: como un archivo de texto lineal. Hay una buena razón para esto. La sintaxis textual es un medio ideal para construir lógica abstracta. Es rápido de escribir, densamente informativo y extremadamente flexible. Sin embargo, la brevedad tiene sus desventajas. ¿Qué información no podemos ver en un texto estático? ¿Cómo pueden las representaciones visuales y las comparaciones metafóricas ampliar nuestra comprensión de cómo funciona React? Ven y descubre qué sucede cuando exploramos formas alternativas de ver React.

31 min
22 Oct, 2021

Video Summary and Transcription

Esta charla explora el uso de imágenes en la programación para hacer los conceptos más accesibles y comprensibles. Se discuten las limitaciones del texto en la programación y los beneficios de visualizar los conceptos de programación. La charla también profundiza en el uso de metáforas visuales en React y las ventajas de utilizar principios espaciales y representaciones visuales para comprender el comportamiento del programa a lo largo del tiempo. Concluye con sugerencias para avanzar en los esfuerzos de programación visual y aprovechar las metáforas existentes en lenguajes y frameworks de programación.

Available in English

1. Introducción a los Programas Pictóricos

Short description:

Esta charla trata sobre hacer imágenes de programas y cómo las visualizaciones pueden hacer que los conceptos de programación sean menos abstractos, más fáciles de entender y más accesibles. Las representaciones visuales llevan conceptos de programación abstractos e invisibles al mundo físico en el que vivimos e interactuamos con objetos físicos. Los conceptos de programación son ideas abstractas que existen en un espacio liminal, separado de nuestro mundo altamente visual, espacial y físico, lo que dificulta la programación.

♪♪ ♪♪ ♪♪ ¡Hola! Me alegra mucho no poder verlos a todos debido a la luz deslumbrante que es realmente útil, pero esto va a salir bien. Bien, sí, estamos listos. Esta charla se llama Una Imagen Vale Más que Mil Programas y se trata de hacer imágenes, y específicamente de hacer imágenes de programas, y con suerte de hacer imágenes que valgan más que mil programas, como dice el dicho tradicional.

Antes de sumergirnos, quiero presentarme rápidamente y hacerles saber que estoy aquí en el escenario hablando con ustedes sobre programas pictóricos. Mi nombre es Maggie. Soy diseñadora, directora de arte, ilustradora, amante de las metáforas y tangencialmente también construyo cosas con React. Pasé los últimos cinco años trabajando como directora de arte en Egghead.io, que es una plataforma educativa para desarrolladores web, pero a partir de la próxima semana, pasaré a ocupar un nuevo cargo, liderando el diseño en Hash.ai. Pero hasta ahora, he pasado toda mi carrera creando representaciones visuales de programas. Durante mi tiempo en Egghead, hice cientos de ilustraciones para las portadas de los cursos que enseñamos. Cada una de ellas comenzaba con un concepto de programación abstracto y tenía que encontrar una forma de representarlo visualmente en una sola imagen. Aprendí a depender mucho de las metáforas visuales para esto, y dar estilo a CSS se convirtió en pintar una casa y organizar tipos se convirtió en trajes de una baraja de cartas. He creado muchos diagramas ilustrados para explicar cómo funciona la herencia de prototipos en JavaScript o qué sucede cuando aplanas un array. Uno que se hizo popular fue un ensayo visual sobre qué son las APIs y cómo funcionan, que se contaba a través de pequeños camareros robóticos que te traen los datos que solicitas. El objetivo era hacer que temas técnicos complejos fueran comprensibles y más fáciles de entender. También colaboré recientemente en un proyecto llamado Just JavaScript con Dan Abramov. Es un curso de JavaScript que enseña los modelos mentales fundamentales del lenguaje a través de diagramas visuales y animaciones. Trabajamos juntos para desarrollar todo este lenguaje visual que era un poco más formal que algunas de las otras ilustraciones que mostré. Cada pieza de sintaxis se correlaciona con una forma visual específica y utilizamos el sistema para explicar conceptos como asignar propiedades o mutar objetos. No estoy mostrando todo este trabajo para presumir, solo quería darte contexto sobre el tipo de imágenes de programación que he creado en el pasado para que tengas una idea de lo que quiero decir cuando hablo de imágenes de programación.

En este proceso de transformar conceptos de programación en imágenes visuales cientos de veces, me he visto obligada a pensar mucho en la forma en que representamos y comunicamos ideas de programación complejas, y he llegado a creer que las representaciones visuales tienen mucho que ofrecernos aquí en el mundo del código. En esta charla te mostraré cómo las visualizaciones pueden hacer que los conceptos de programación sean menos abstractos, más fáciles de entender y más accesibles para más personas. También te mostraré por qué las visualizaciones son tan especiales y resulta ser relativamente simple, y es porque las visualizaciones llevan conceptos de programación abstractos e invisibles al mundo físico. El mundo físico es donde tú y yo vivimos. Todos los que están viendo esta charla tienen un cuerpo y lo usan para interactuar con objetos físicos a su alrededor, moverse a través del espacio y experimentar eventos a lo largo del tiempo. Todo lo que sabes sobre el mundo se mediatiza a través de tu cuerpo y este hecho es tan fundamental que a veces lo olvidamos por completo. Y los conceptos de programación son ideas abstractas que no viven aquí en el mundo físico con nosotros. Son objetos e funciones imaginarios que existen en el espacio liminal que parece no obedecer las mismas leyes de la física que nosotros. Y solo podemos interactuar con ellos a través de esta experiencia desencarnada de escribir caracteres de texto lineales en un editor de código. Esto es precisamente lo que hace que la programación sea tan difícil. Estamos tratando de razonar y trabajar con cosas que no podemos ver o tocar cuando somos criaturas que están adaptadas evolutivamente para funcionar en un mundo altamente visual, espacial y físico.

2. Las Limitaciones del Texto en la Programación

Short description:

Y creo que las representaciones visuales son una gran parte de cerrar la brecha entre nuestro mundo humano encarnado y el mundo desencarnado de las máquinas en el que intentamos programar. Vamos a explorar este tema a través de tres preguntas. Primero, ¿qué está mal con el texto? Todos nuestros lenguajes de programación actuales, herramientas y documentación se centran abrumadoramente en el texto. Si observamos la historia de la programación, es bastante claro cómo terminamos en un mundo dominado por el texto. También hay muchas razones lógicas por las que dependemos tanto del texto en la programación. La naturaleza abstracta del texto es lo que lo separa de nuestras experiencias encarnadas en el espacio y el tiempo.

Y creo que las representaciones visuales son una gran parte de cerrar la brecha entre nuestro mundo humano encarnado y el mundo desencarnado de las máquinas en el que intentamos programar. Así que aquí está el plan. Vamos a explorar este tema a través de tres preguntas.

Primero vamos a preguntar qué está mal con el texto, luego exploraremos qué pueden hacer las representaciones visuales que el texto no puede, y finalmente haremos un breve recorrido histórico para descubrir si ya hemos intentado esto antes. Después de todo, no hay ideas nuevas bajo el sol y muchas personas en el pasado han explorado formas de hacer la programación más visual. Vamos a ver qué se ha intentado y qué oportunidades aún quedan.

Entonces, primero, ¿qué está mal con el texto? Esta es una pregunta importante porque todo lo que hacemos en programación se expresa en texto. Cada aplicación en la que has trabajado se ve así, ¿verdad? Es texto organizado en líneas que van de izquierda a derecha y de arriba a abajo. Aquí tienes cada sitio web de documentación que has utilizado. Aquí tienes cada publicación de blog que has leído. Todos nuestros lenguajes de programación actuales, herramientas y documentación se centran abrumadoramente en el texto. A veces obtienes algunos diagramas aquí y allá, pero es realmente escaso. Si tuviera que adivinar el equilibrio entre texto y representaciones visuales en nuestra industria, apostaría a que estamos en un 98% de texto y un 2% de representaciones visuales. Esto no se basa en una encuesta oficial y no pude encontrar a nadie que haya realizado una encuesta oficial, así que esto se basa en mi experiencia personal en la comunidad de desarrollo web. Pero si te tomas un minuto y piensas en todo el código y la documentación con los que interactúas a diario, apuesto a que llegarás a una estimación similar.

Si observamos la historia de la programación, es bastante claro cómo terminamos en un mundo dominado por el texto. Esta es una computadora, circa 1970. Notarás la falta de pantalla. Tenías un teclado y una pila de tarjetas perforadas, y lo único que podías hacer era escribir texto lineal para crear programas. Esta limitación de diseño significaba que todos nuestros primeros lenguajes de programación se basaban en texto, y una vez que estableces el texto como el paradigma principal de un campo, se vuelve muy difícil alejarse de él. Especialmente en una industria donde dependemos tanto de abstracciones de bajo nivel creadas por todos los programadores que vinieron antes que nosotros. También hay muchas razones lógicas por las que dependemos tanto del texto en la programación. Las palabras escritas y la sintaxis son un medio ideal para expresar lógica abstracta. Es rápido de crear, flexible y fácil de mover entre aplicaciones mediante copiar y pegar sin preocuparse por la compatibilidad. Puedes empaquetar una cantidad densa de información en un espacio muy pequeño y puedes ser muy específico acerca de lo que quieres decir, lo cual obviamente importa cuando estamos hablando con computadoras que no tienen sentido de matices.

Hasta ahora, el texto ha funcionado muy bien para nosotros en la programación. Pero algunas de las mayores fortalezas del texto también son sus mayores debilidades. La naturaleza abstracta del texto es lo que lo separa de nuestras experiencias encarnadas en el espacio y el tiempo. Cuando programamos, estamos escribiendo un conjunto de instrucciones hipotéticas para ejecutar en la máquina de otra persona en algún momento del futuro en un tiempo y lugar que nunca conoceremos. Este nivel de abstracción elimina las cualidades físicas, espaciales y encarnadas en las que los humanos confiamos para comprender el mundo que nos rodea. Esto puede ser bueno en ciertos aspectos, ¿verdad? Si queremos escribir una función como obtener datos de usuario, no tenemos que definir su tamaño, forma o color.

3. Visualizando Conceptos de Programación

Short description:

Las representaciones visuales, como cajas y flechas, pueden ayudar a explicar conceptos de programación, como la función de obtener datos de usuario, a los principiantes. Al utilizar cualidades físicas familiares, como el tamaño, la forma, el color y las relaciones espaciales, podemos hacer que la programación sea más comprensible y accesible. Estas representaciones visuales aprovechan nuestro conocimiento incorporado previo para demostrar cómo funcionan los programas, algo que el texto lineal por sí solo no puede lograr.

Es solo una función simple flotando en el mundo de las máquinas. Si ya sabes qué es esta función, cómo funciona y dónde se encuentra, este nivel de brevedad es genial. Pero imagina a alguien nuevo en la programación que nunca ha escrito una función para obtener datos de usuario y no tiene un modelo mental previo de cómo podría funcionar. Una de las formas más fáciles y efectivas de hacerlo comprensible para ellos es explicarlo en términos familiares utilizando cualidades físicas que ya entienden, como el tamaño, la forma, el color y las relaciones espaciales. Esto podría resultar en algo como esto para ayudar a explicar qué hace una función de obtener datos de usuario. La visualización no tiene que ser extremadamente compleja o hermosa. Las cajas y las flechas funcionan muy bien. Por supuesto, podemos usar etiquetas de texto para que la imagen sea clara. Las representaciones visuales como esta nos permiten utilizar nuestro conocimiento incorporado previo para mostrar cómo funcionan los programas de una manera que el texto lineal no puede hacer.

4. Visualización y Metáforas Cognitivas en la Programación

Short description:

Las representaciones visuales revelan tres aspectos de la programación que no podemos ver en un texto lineal: metáforas fundamentales, mapeos espaciales y comportamiento del programa a lo largo del tiempo. Las metáforas en la programación son metáforas cognitivas basadas en nuestras experiencias corporales del mundo. Utilizamos metáforas para comprender y comunicar conceptos abstractos. El campo de la metáfora cognitiva y la cognición incorporada, desarrollado en la década de 1980 por George y Mark Johnson, explora este tema de manera extensa.

Acabo de comenzar a insinuar la pregunta que vamos a analizar en la segunda parte, que es: ¿qué nos pueden ofrecer las representaciones visuales que no podemos obtener del texto lineal? Creo que las representaciones visuales revelan tres aspectos de la programación que no podemos ver en el texto lineal. Revelan metáforas fundamentales incorporadas en nuestros lenguajes de programación. Revelan mapeos espaciales que utilizamos para razonar sobre cómo están estructurados nuestros programas y cómo los datos se mueven a través de ellos, y revelan cómo se comportan nuestros programas y los datos a lo largo del tiempo. Estas cosas son implícitas en los programas que escribimos, pero no se muestran explícitamente en el medio del texto lineal. Comencemos con las metáforas. Para asegurarnos de que todos estemos en la misma página, establezcamos que las metáforas son herramientas de pensamiento que nos permiten comprender una cosa en términos de otra. Supongamos que tenemos la cosa A aquí, que entendemos, y la cosa B, que no entendemos. Mapeamos las cualidades de la cosa A en ella. Si decimos que la corrupción es una enfermedad, entendemos que la corrupción se propaga, es difícil de superar y, si no se controla, puede ser mortal. De manera similar, decimos que la vida es un viaje. Hay muchos caminos que nuestra vida podría tomar y varían en longitud, y todos tienen un comienzo y un destino final. Cuando hablo de metáfora en el contexto de la programación, no me refiero a las metáforas creativas y caprichosas que se encuentran en la poesía, como tomar el camino menos transitado y vagar solitario como una nube. Esas se llaman metáforas figurativas o poéticas y a menudo se nos advierte que no las usemos en tutoriales técnicos, ya que las metáforas elaboradas y mal elegidas pueden ser más confusas que útiles. Estoy hablando de un tipo de metáfora mucho más fundamental que se encuentra en el corazón de todo pensamiento abstracto, incluida la programación. Estas se llaman metáforas cognitivas, ya que permiten la cognición a un nivel mucho más profundo. Estas metáforas cognitivas se basan en nuestras experiencias corporales del mundo. Tenemos todas estas cosas no físicas que necesitamos comunicarnos entre nosotros, como emociones, pensamientos, ideas y conceptos de programación. Para comprenderlos y hablar sobre ellos, utilizamos nuestra experiencia del mundo físico que nos rodea como una metáfora. Si observamos la forma en que hablamos de cosas abstractas, esto se vuelve obvio. Hablamos de ideas en términos de luz cuando decimos que es una idea brillante o que iluminó realmente el problema. Hablamos de las emociones como si fueran objetos. Decimos que él ocultó su envidia o que ella no maneja bien la ira. También podemos usar metáforas de fuerza y movimiento para describir experiencias. Podemos decir que tu charla me conmovió o que tu charla realmente me tocó. Programamos en términos de temperatura. Tenemos la recarga en caliente en React o el panorama de JavaScript se está calentando. Esto no es una teoría que acabo de inventar. Estos principios provienen del campo de la metáfora cognitiva y la cognición incorporada. Fueron desarrollados por primera vez en la década de 1980 por George y Mark Johnson, quienes han escrito numerosos libros sobre este tema y se ha convertido en un área importante de investigación en la ciencia cognitiva. Estos dos libros, Philosophy in the Flesh y Metaphors We Live By, son dos de los principales. Pero no puedo profundizar demasiado en esto aquí.

5. Metáforas Físicas Encarnadas en la Programación

Short description:

La programación se basa en gran medida en metáforas físicas encarnadas para cerrar la brecha entre el mundo abstracto de las máquinas y nuestro mundo humano tangible. Utilizamos metáforas y abstracciones para simplificar el complejo proceso de programación y hacerlo más accesible. Estas metáforas sirven como puente entre las compuertas lógicas de los microchips y los lenguajes de nivel superior que utilizamos.

Entonces, con suerte, puedes hacer un doctorado en ello. Y al igual que cualquier otro tema abstracto que no podemos ver o tocar, la programación se basa en gran medida en estas metáforas físicas encarnadas y tenemos que hacerlo porque la programación en sí es un juego de abstracciones, ¿verdad? Escribimos un archivo JavaScript y lo que realmente estamos haciendo es indicarle a un microchip que cambie un montón de compuertas lógicas utilizando pulsos eléctricos diminutos. Esto es tedioso y difícil para los humanos, por lo que hemos desarrollado una serie de metáforas elaboradas que lo hacen más rápido y fácil. Algunas personas podrían preferir llamar a estas abstracciones, pero para los fines de esta charla, asumamos que las metáforas y las abstracciones son más o menos lo mismo y podemos debatir las diferencias en Twitter más tarde.

6. Metáforas Visuales en React

Short description:

Simplificamos nuestro código binario en código de máquina y luego en lenguajes de nivel superior como JavaScript y en interfaces gráficas de usuario. En React, los componentes son contenedores que contienen conjuntos de elementos de interfaz de usuario. En React, los componentes se estructuran en un árbol jerárquico, similar a un árbol genealógico, lo que permite una interacción fácil con las máquinas. Los medios visuales facilitan la representación y explicación de React al aprovechar nuestro conocimiento previo del mundo físico. Se utilizan conceptos espaciales, como arriba, abajo, izquierda, derecha, dentro, fuera, grande, pequeño, como metáforas para comprender los programas y su estructura.

Simplificamos nuestro código binario en código de máquina, que luego simplificamos en lenguajes de nivel superior como JavaScript, que a su vez simplificamos en interfaces gráficas de usuario. En cada paso de este proceso, intentamos hacer que el mundo abstracto de las máquinas se asemeje a nuestro mundo humano tangible. Cuanto más nos acercamos al conocimiento intuitivo encarnado en la parte superior derecha de la escala, más fácil se vuelve para nosotros comprender lo que está sucediendo en un sistema.

Los componentes en React son un gran ejemplo de estas metáforas encarnadas en acción. Los componentes son básicamente contenedores que contienen conjuntos de elementos de interfaz de usuario. Por ejemplo, un componente de tarjeta puede tener una imagen, un botón y un párrafo en su interior. La CPU que va a renderizar este componente en la pantalla no sabe nada acerca de los contenedores. Solo conoce el código de máquina y cómo hacer que los píxeles correctos se iluminen. El contenedor es una metáfora que los humanos necesitamos para gestionar y organizar el código que escribimos. La única razón por la que sabes qué es un contenedor es porque de niño, echaste arena en un cubo y luego la volviste a sacar. A través de esta experiencia física, aprendiste que los contenedores contienen cosas. Tienen un interior y un exterior. Tienen límites. Todos estos conceptos son esenciales y necesarios para comprender cómo funcionan los componentes en React.

Veamos otro ejemplo. En React, estructuramos nuestros componentes en un árbol jerárquico donde todo está conectado a un único componente raíz. Sabes qué es un árbol porque has visto miles de árboles, y entiendes que tienen muchas ramas que se extienden desde una única raíz, una comprensión que te permite trabajar con árboles de componentes en React. La metáfora del árbol también es una especie de doble metáfora, ya que se basa en la idea de un árbol genealógico. Tenemos componentes padres e hijos que heredan propiedades de la misma manera en que los hijos heredan cualidades de sus padres, y estos conceptos que estamos tomando prestados del mundo humano nos permiten interactuar con las máquinas de una manera fácil y natural para nosotros. Probablemente puedas ver hacia dónde me dirijo con esto. Dado que tu comprensión de React se basa en tu conocimiento previo del mundo físico que te rodea, sería útil si pudiéramos hacerlo explícito en la forma en que representamos y explicamos React. Los medios visuales nos permiten hacer esto. Puedes leer sobre las estructuras de los componentes de React y cómo se transmiten las propiedades, y luego formar una imagen mental en tu mente basada en tu comprensión de los árboles físicos y la herencia familiar, y luego aplicar ese conocimiento para escribir código lineal, todo sin verlo explícitamente visualizado. Pero eso se llama hacerlo más difícil de lo necesario. Pasemos a la siguiente cualidad visual, el espacio. Como seres humanos con cuerpos, entendemos inherentemente una amplia gama de conceptos espaciales como arriba, abajo, izquierda, derecha, dentro, fuera, grande, pequeño, y utilizamos metáforas al igual que utilizamos conceptos físicos para comprender los programas. También utilizamos conceptos espaciales para hablar sobre la estructura y el comportamiento de los programas. Si piensas en la forma en que hablamos sobre Internet, hay direcciones físicas muy claras para ello.

7. Principios Espaciales y Cambio a lo Largo del Tiempo

Short description:

Utilizamos principios espaciales de nuestra experiencia corporal del mundo para hablar y comprender React. Las imágenes pueden ser útiles porque nos permiten ver múltiples puntos en el tiempo dentro de un solo cuadro. Veamos la sintaxis del gancho useEffect como ejemplo de esto. Aquí hay cuatro versiones diferentes del gancho useEffect que se comportarán de manera diferente cuando se ejecuten en el navegador.

Subimos data a la nube que está sobre nosotros y descargamos archivos en nuestros escritorios. Miramos a través de una ventana del navegador. Navegamos por páginas web moviéndonos de izquierda a derecha. Por lo tanto, las páginas que visitaste en el pasado están a la izquierda y las páginas a las que vas en el futuro están a la derecha. Este formato se basa en nuestra representación cultural occidental del tiempo en el espacio. Pensamos que el pasado está a la izquierda y el futuro a la derecha, pero no todas las culturas lo hacen de esa manera.

Específicamente en React, utilizamos nuestra comprensión de las direcciones verticales para pensar en cómo se mueve data. React tiene un orden jerárquico de componentes y los componentes padres están por encima de los hijos y pasan data hacia abajo, lo que significa que tenemos gravedad en el mundo de React. La idea de prop drilling es otra que sugiere perforar hacia abajo, por lo que debes pasar data profundamente en tu árbol, por lo que también tiene profundidad. Cuando hablamos de efectos secundarios, utilizamos nuestra comprensión de que hay un centro y una periferia donde ocurren cosas en el lado, por lo que cuando ejecutamos una función como un setTimeout dentro de un gancho useEffect, entendemos que está accediendo algo fuera de nuestro componente central. Podría seguir. Nuestras aplicaciones tienen frentes y partes traseras, emergen objetos, entiendes el punto aquí. Utilizamos principios espaciales de nuestra experiencia corporal del mundo para hablar y comprender React. Cuando creamos imágenes que muestran estos principios espaciales de manera explícita, aclara lo que ya estamos haciendo en nuestras mentes.

Nuestro último elemento aquí es el cambio a lo largo del tiempo. Cuando trabajamos en un editor de texto lineal, el tiempo es esencialmente invisible. Estamos viendo una representación estática que describe una serie de eventos futuros que pueden o no ocurrir dependiendo de qué botón haga clic un usuario o si nuestra solicitud de data se resuelve. Nos vemos obligados a usar nuestra imaginación para predecir qué va a suceder en todos esos futuros potenciales, en lugar de poder verlo de alguna forma. Nuestra mejor técnica actual para tratar de ver cómo cambian las cosas a lo largo del tiempo es la consola de registro de data en el camino. La consola de registro se siente como tratar de hacer que un programa envíe señales a la superficie de un océano oscuro donde todo se ejecuta fuera de la vista. No podemos ver nada que suceda allí abajo y tenemos que seguir pidiendo pistas sobre cómo está cambiando data, lo que no parece ser la mejor experiencia para el desarrollador. Aquí es donde las imágenes pueden ser útiles porque nos permiten ver múltiples puntos en el tiempo dentro de un solo cuadro. Nos permiten comparar cosas lado a lado de una manera que no podemos hacer con texto lineal. Básicamente nos permiten encontrar las diferencias. Veamos la sintaxis del gancho useEffect como ejemplo de esto. Aquí hay cuatro versiones diferentes del gancho useEffect que se comportarán de manera diferente cuando se ejecuten en el navegador. La primera no tiene una matriz de dependencias. La segunda tiene una vacía. La tercera tiene el valor count como dependencia, y la cuarta también tiene count como dependencia y ejecuta una función de limpieza. Solo con mirar estas cuatro versiones de sintaxis, ¿tienes alguna forma de saber cómo se ejecutará esta función una vez que se cargue en el navegador? Específicamente, ¿sabes con qué frecuencia se llamará y cuándo? Dada la demografía de esta audiencia, apuesto a que sí lo sabes.

8. Visualizando el Comportamiento del Gancho use effect

Short description:

Para comprender mejor cómo se comporta el gancho use effect a lo largo del tiempo, he creado diagramas visuales que demuestran las diferencias en el comportamiento basado en diferentes escenarios. Al representar visualmente los cambios a lo largo del tiempo, podemos obtener una comprensión más profunda de cómo funciona el gancho use effect.

Es porque has memorizado el significado sintáctico aquí en lugar de saberlo porque la respuesta es visible en nuestra sintaxis. Lo que necesitamos hacer aquí es comparar cuatro cosas que se comportan de manera diferente a lo largo del tiempo. La mejor manera de hacerlo es mostrar visualmente qué cambios ocurren a lo largo del tiempo. He creado un conjunto simple de diagramas que intentan mostrar la diferencia entre estos cuatro en una línea de tiempo. Aquí está nuestra primera versión sin dependencia en el RRA. La función use effect se llama en cada renderizado independientemente de si nuestra variable de conteo se actualiza o no. Aquí está nuestra segunda versión donde la matriz de dependencia está vacía, por lo que la función use effect solo se llama en el renderizado inicial, y aún no nos importa lo que la variable de conteo esté haciendo. En nuestra tercera versión, con el conteo en la matriz de dependencia, use effect solo se llama cuando el conteo se actualiza, lo que provoca un nuevo renderizado. En nuestra versión final, use effect se llama cuando se actualiza el conteo y se ejecuta una función de limpieza después. Incluso si quitamos las etiquetas de estos, esta representación visual simple de cómo use effect se comporta a lo largo del tiempo nos brinda una comprensión mucho mejor de cómo funciona que la sintaxis lineal puede proporcionar.

9. Explorando la Programación Visual

Short description:

En el pasado, se ha explorado la programación visual mediante la incorporación de interfaces gráficas de usuario en los entornos de desarrollo integrados (IDE). Sin embargo, estos intentos han enfrentado desafíos de diseño y escepticismo. La programación visual aún es relativamente especializada, pero el movimiento de código bajo y sin código muestra promesa. En lugar de construir lenguajes de programación visual completos, el enfoque se ha centrado en desarrollar interfaces visuales para casos de uso específicos en la programación. Aunque construir un medio de programación visual verdadero es desafiante, existen formas más sencillas de avanzar en este esfuerzo a corto plazo.

Entonces, ¿no hemos intentado esto antes? Obviamente, no soy la primera persona en darme cuenta de que los medios visuales nos permiten comprender y razonar de maneras que vale la pena explorar en la programación. La forma principal en que las personas han intentado incorporar elementos visuales en la programación en el pasado es mediante la adición de interfaces gráficas de usuario a los IDE. Estos esfuerzos se engloban en lo que se conoce como programación visual.

Ha habido muchos intentos en el pasado con diferentes grados de éxito. Voy a repasar rápidamente algunos ejemplos para que tengas una idea de lo que ya se ha intentado. El primer lenguaje de programación visual fue Sketchpad de Ivan Sutherland en 1963. Luego tenemos Grail de 1968, donde por primera vez colocamos texto en cuadros. Luego tenemos Pygmalion de 1975, que se basó en ese modelo de cuadros y flechas. Luego tenemos LabVIEW, que salió en 1986 y se utiliza para la ingeniería de sistemas, y en esta etapa nos volvimos mucho más intensos con los cuadros. Aquí tenemos un ejemplo más moderno. Blueprint en Unreal Engine, que se utiliza para el desarrollo de juegos en 3D. También tenemos Max MSP, que se utiliza ampliamente para crear experiencias audiovisuales. Y luego tenemos TouchDesigner, también para multimedia interactivo. Y esto es Origami Studio, una herramienta de prototipado creada por Facebook. Notarás que el patrón de nodos y cables es muy popular en muchos de estos ejemplos.

Entonces, hay muchas cosas prometedoras en estos ejemplos, pero la programación visual aún es relativamente especializada. También hemos descubierto una serie de desafíos de diseño realmente difíciles de resolver. Estos sistemas no escalan bien, a veces utilizan símbolos ambiguos e interfaces poco familiares. Intentan convertir todo en un cuadro, lo que ocupa demasiado espacio en la pantalla. Esto puede llevar a un código literalmente enredado. Aquí tenemos un prototipo de Figma que salió muy mal. Estos problemas han generado mucho escepticismo sobre la viabilidad de la programación visual. Ser un defensor de esto a menudo se siente como ser Gretchen en Mean Girls. Sin embargo, la programación visual ciertamente no está muerta. Curiosamente, el nuevo movimiento de código bajo y sin código se parece a la programación visual con un nuevo nombre. Muchos de los patrones de interfaz que ayuda a desarrollar la programación visual son visibles en herramientas como IntegroMet, Zapier y Webflow. Pero en lugar de intentar construir lenguajes de programación visual que puedan alcanzar escalas industriales, hemos pasado tácticamente a desarrollar interfaces visuales para casos de uso específicos en la programación con restricciones sensatas. Soy un gran admirador de la agenda de programación visual y de encontrar formas de agregar más affordances visuales a las herramientas de desarrollo actuales, y hay muchas personas inteligentes e impresionantes trabajando en el problema, pero de muchas maneras, es el camino difícil. Construir un medio de programación visual verdadero requerirá superar una gran cantidad de desafíos de diseño, culturales e ingenieriles, y francamente llevará tiempo.

10. Avanzando en los Esfuerzos de Programación Visual

Short description:

Podemos agregar elementos visuales a nuestro mundo textual existente mediante la adición de diagramas, ilustraciones y complementos. Se necesitan más elementos visuales para revelar metáforas, significado espacial y cambios a lo largo del tiempo en la programación. Los desarrolladores deben aprender de la historia de la programación visual, incorporar elementos visuales en sus herramientas y utilizar explicaciones y documentación visual. Consulta a George Laycoff, Mark Johnson, Barbara Javersky, Brett Victor, futureofcoding.org y el libro Visual Explanations de Edward Tufte para obtener más información.

Pero hay formas más sencillas de avanzar en este esfuerzo a corto plazo. Simplemente podemos agregar algunos elementos visuales a nuestro mundo textual existente, lo que significa agregar más diagramas e ilustraciones a publicaciones de blog, documentación y materiales de aprendizaje y, si nos sentimos valientes, construir complementos para nuestros editores y herramientas de desarrollo que visualicen elementos muy pequeños y específicos de nuestros programas. Esta es básicamente la versión de prototipo en papel de baja tecnología de construir una interfaz de programación visual completamente desarrollada.

Entonces, para resumir esto, aquí está lo que quiero que te lleves de esta charla. Necesitamos más elementos visuales que revelen metáforas, significado espacial y cambios a lo largo del tiempo para facilitar la programación para todos. Te facilitará a ti, ya que eres un ser humano encarnado que necesita aprender conceptos de programación complejos y abstractos para hacer bien tu trabajo. Facilitará a todas las personas que actualmente no saben programar pero están intentando aprender, y facilitará a las personas que no son desarrolladores pero necesitan entender lo que hacemos, como los gerentes de producto y los diseñadores que no pueden leer todo el jerga en nuestra documentación llena de texto.

Entonces, ¿qué debe hacer un desarrollador? Estoy seguro de que eres un humilde pero hábil desarrollador de React y quieres ayudar a avanzar en este objetivo. En primer lugar, te sugiero encarecidamente que investigues la historia de la programación visual y algunos de los intentos anteriores en este campo. Hay mucho arte anterior bueno del que aprender. Si eres un creador actual o futuro de herramientas para otros desarrolladores, debes considerar formas de incorporar elementos visuales en tus bibliotecas, complementos, aplicaciones o frameworks. Y finalmente, debes utilizar y promover explicaciones visuales y documentación y tutoriales. Eso puede significar crearlos para tus propias publicaciones de blog o colaborar con diseñadores si trabajas en proyectos más grandes con mucha documentación. Así que podemos establecer un objetivo bajo por ahora. Estamos tratando de aumentar esta estadística falsa hasta, digamos, un diez por ciento. Así que eso fue mucha información en una sola charla. Esto fue definitivamente una sesión de degustación más que una comida completa, así que he reunido una lista de algunas cosas que puedes buscar en Google para aprender más sobre este tema. Estarán disponibles en mi sitio web. George Laycoff y Mark Johnson son quienes trabajaron en metáforas cognitivas. El trabajo de Barbara Javersky sobre la cognición encarnada es excelente. Todo lo que Brett Victor ha creado vale la pena tu tiempo. Y hay algunos recursos realmente buenos en futureofcoding.org, son una especie de comunidad entusiasta de programación visual. Y el libro Visual Explanations de Edward Tufte es realmente bueno para obtener consejos. Así que muchas gracias por escuchar. Publicaré esto en mi sitio web, maggieaffleton.com, donde tengo más escritos sobre metáforas y programación visual y ese tipo de cosas. Y puedes enviarme un tweet a mappletons. Increíble. Gracias, Maggie. Por favor, ven y únete a mí en la oficina. Eso fue realmente increíble.

11. Llegando a las Metáforas Visuales

Short description:

Cuando llego a una metáfora visual, razono verbalmente a través de ella y confío en la lingüística para analizar el lenguaje utilizado en torno al concepto. Presto atención a las palabras físicas utilizadas en la documentación, como mover, pasar y términos espaciales, para diseñar la metáfora.

Y la gente tiene un montón de preguntas. Así que vamos directo al grano. L, la letra, pregunta cómo llegas a una metáfora visual. ¿Es algo que se forma inconscientemente mientras te involucras con el concepto? ¿O razonas verbalmente a través de ello? Definitivamente razono verbalmente a través de ello e investigo. Así que confío mucho en la lingüística y en las técnicas que los lingüistas utilizan para analizar el lenguaje que utilizamos en torno a las cosas. Así que cuando intento designar una metáfora para una determinada tecnología, leo la documentación y presto mucha atención a las palabras que están utilizando. Y casi siempre están utilizando palabras físicas. Se están moviendo, pasando, ya sabes, cosas espaciales. Hablan de cómo se organizan las cosas en el espacio aunque solo estén escribiendo en texto lineal. Pero presto mucha atención al lenguaje.

12. Stickers, Colaboración, Herramientas y Metáforas

Short description:

Hay interés en pegatinas y merchandising, pero no tengo una tienda. La colaboración con el equipo de documentación de React está en progreso. Para una exploración más profunda, visita mi sitio web. Utilizo un iPad con Procreate para las ilustraciones. Las metáforas pueden ser interpretadas de manera diferente por diferentes culturas, pero en la comunidad de desarrollo web, tenemos una comprensión compartida.

Hay más de una pregunta preguntando si tienes pegatinas o merchandising de tus ilustraciones. ¡La gente necesita más Maggie! Personalmente no vendo nada. Egghead tiene un sitio de regalos donde venden algunas pegatinas de las ilustraciones del curso. Pero también tendemos a regalarlas gratis cuando asistimos a conferencias. Pero no tengo una tienda de regalos organizada. Lo siento.

Y de manera similar, nuevamente, la gente realmente está interesada. ¿Hay alguna posibilidad de colaboración con el nuevo equipo de documentación beta de React? Creo que puedo decirlo. Es posible que tenga algunas imágenes en la nueva documentación de React. Increíble. Están en progreso.

Uh, sí. Lo sé, ¿verdad? ¿Qué recursos recomendarías para alguien que quiera explorar estos conceptos más a fondo? Sé que mencionaste un par. ¿Hay algo más que te gustaría agregar? Creo que es mejor ir a mi sitio web donde tengo esa lista en la sección de imágenes de programación. Agregaré más allí. Porque tengo una lista larga. Pero llevaría tiempo leerlas todas.

Un par de personas están interesadas en las herramientas. ¿Qué utilizas para dibujar, para agregar tus ilustraciones a la presentación, etc.? Todas las ilustraciones que dibujo actualmente las hago en un iPad con Procreate. Solía dibujar más en Photoshop en un Cintiq. Para ser honesto, son casi intercambiables y el iPad es simplemente mejor. Hemos tenido avances mucho mejores en hardware y software en los últimos cinco años que el iPad es algo así como el estado del arte.

Esto es interesante. ¿Crees que ... Estoy seguro de que sí. ¿Potencialmente hay un problema de que las metáforas sean interpretadas de manera diferente por diferentes países y culturas y cómo pensamos en eso? Definitivamente, las metáforas son increíblemente culturales. Casi todas las metáforas que usamos están limitadas al país en el que estamos y al idioma en el que hablamos. Dado el hecho de que React y la comunidad de desarrollo web es un lugar bastante unificado y todos tenemos una comprensión compartida de las metáforas y los símbolos. Encuentro que no es tan difícil encontrar metáforas que sean relevantes para todos. Aunque siempre estoy consciente de que si alguien en otro país que no tiene muchas de las mismas asociaciones que nosotros lo ve, es muy probable que se pierda matices de ello.

13. Aprovechando Metáforas Existentes en la Programación

Short description:

¿Deberíamos aprovechar las metáforas existentes en los lenguajes de programación y frameworks? El diseño de los lenguajes de programación incorpora metáforas que se consideran apropiadas. Cuando no hay una metáfora clara, se vuelve necesario inventar una.

Eso es algo que debes considerar caso por caso. Necesitaremos a Maggie en todos los países y en todas las zonas horarias, por si acaso. ¿Deberíamos, crees tú, aprovechar las metáforas existentes que ya están en nuestros lenguajes de programación y frameworks? ¿O intentar optimizar las que quizás comuniquen algo bien? Esa es una buena pregunta. Casi se convierte en una pregunta de diseño de lenguaje de programación. Me gusta asumir que las personas que diseñaron el lenguaje de programación pensaron lo suficiente en las abstracciones y en el lenguaje de la API, y que las metáforas que han elegido, ya sea consciente o inconscientemente, son las correctas. No trato de inventar nuevas metáforas sobre eso si estoy tratando de dibujar algo que realmente pretende explicar el punto. Pero a veces, si no parece haber una metáfora clara, es cuando empiezas a inventar una que se ajuste a las necesidades. Sí. Eso es muy interesante. Aquí hay un par de preguntas que son sobre ti y tu proceso. ¿Comenzaste programando y luego te metiste en el design, o viceversa? ¿Cuál es un poco más tu proceso para convertir los conceptos de programación en programming concepts? Mencionaste que lees un poco la documentación. ¿Hay algo más por lo que pases? La documentación y luego hago cosas como navegar por Reddit y Twitter y solo busco el lenguaje que la gente usa todos los días en torno a la tecnología, si eso responde a la pregunta. ¿Y cuál vino primero? Ambos al mismo tiempo. Empecé a jugar con HTML cuando tenía 12 años y había un gran deseo de hacer cosas bonitas en la web, ese fue el impulso. Así que siempre he hecho ambas cosas y he pasado por diferentes períodos de intensidad para cada una. Creo que cuando empecé a aprender React hace seis años, me metí mucho más en la programación durante unos años y antes de eso era principalmente diseño. Pero siempre he ido y venido. ¿... esto es solo una idea, haces muchos dibujos en papel y lápiz alguna vez? Sí. Casi todos mis dibujos comienzan en notas adhesivas con un lápiz, y el iPad es realmente solo el paso final, pero hay muchos bocetos en el medio donde estoy tratando de entender las cosas, y la versión final pulida casi nunca es lo que lleva tiempo o más esfuerzo. ¿Alguna vez encuentras un dibujo y no recuerdas para qué era? ¿Hago qué? ¿Encuentras un dibujo y no recuerdas para qué era? Oh, sí. No, sí. Miro hacia atrás, como de la misma manera que encuentras notas de hace 10 años y dices, no entiendo ni siquiera para qué se suponía que era esto. Tenemos tiempo para una más. Drew pregunta, ¡ayuda! Soy terrible en design y dibujo. ¿Qué puedo hacer? Ooh. Tengo en mi sitio web una lista completa de todos mis cursos, libros y enlaces favoritos y cosas que tratan sobre las técnicas de cómo dibujar un círculo correctamente, cómo hacer que un rostro humano se parezca a un rostro humano. Ese tipo de contenido técnico de dibujo, sí. La sección de recursos en mi sitio web será una buena fuente para ti. Muchas gracias, Maggie, por tu tiempo. Encuentra a Maggie en internet. Claramente hay excelentes recursos allí. Muchas gracias a Maggie, por favor.

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 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.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

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