Separando la Separación de Preocupaciones

Mi nombre es Jacob. Vivo aquí, trabajo aquí y mi preocupación hoy es decirles que mi preocupación es lo que estoy intentando hacer y cómo logro eso necesariamente reflejará mi comprensión de mi preocupación. Un excelente primer ejemplo es hablar de una aplicación de tareas pendientes. Si elijo concebir mi aplicación de tareas pendientes como la administración de una lista de tareas no interconectadas, entonces probablemente escribiré código que mapee de una matriz de tareas no interconectadas a una matriz de elementos, y lo insertaré en el DOM, y eso será mi funcionalidad principal, pero eso no será toda la aplicación. Probablemente al menos tendré un encabezado y tendré un div alrededor de eso y tal vez un pie de página y tal vez algunos análisis y tal vez algunos rastreadores. Y voy a representar todo eso como una estructura de árbol, y para instanciar esa estructura de árbol, voy a usar el DOM porque la web es buena. Y lo que nos encontramos de inmediato es que nuestros encabezados no son solo una semántica presentacional. No tienen simplemente esa preocupación. Al enmarcar la funcionalidad, habilitan la funcionalidad. No podríamos interactuar con esta aplicación si no supiéramos qué es y cómo hacerlo. Entonces, este tipo de preocupaciones transversales, es útil ubicarlos en el mismo lugar en lugar de separarlos en archivos HTML, CSS, JavaScript. Y eso es lo que React quería decir cuando hablaba de separación de preocupaciones en lugar de separación de tecnologías. Otro conjunto de preocupaciones que hemos ubicado en todos nuestros componentes son nuestras preocupaciones de funcionalidad y nuestras preocupaciones de eficiencia. Y estas fueron las dos preocupaciones principales de las que hablaba Dijkstra cuando introdujo el término separación de preocupaciones en su artículo seminal sobre el papel del pensamiento científico. El pasaje más pertinente es el siguiente. Un programa debe ser correcto y solo podemos estudiarlo desde ese punto de vista. También sabemos que debe ser eficiente. Podemos estudiar su eficiencia en otro momento, pero no se gana nada abordando estos diversos aspectos simultáneamente. Es lo que a veces llamo la separación de preocupaciones, que es la única técnica disponible para un ordenamiento efectivo de los pensamientos. Y cuando hablamos de eficiencia en el mundo de React y en la industria en general, es como si fuera el inverso preciso de la abstracción. Porque React es más abstracto que JS, se deduce que podemos esperar que React sea significativamente más lento que JS, pero esto no es realmente el caso. Si observamos un fragmento de JS, digamos 3JS, y observamos React 3 fiber, vemos que React 3 fiber es en realidad más rápido que el vanilla 3. Y lo que esto nos dice es que podemos estar concebiendo mal a React. Podemos estar pensando que React es todo un marco cuando puede ser algo más cercano a una biblioteca que tiene una preocupación particular de tratar, en este caso, la programación. Y una de las desventajas de este modo de concebir es que cuando estructuramos nuestras aplicaciones incorrectamente, no podemos aprovechar React. Uno de los mayores problemas en React es que nuestros componentes se vuelven a renderizar con demasiada frecuencia. Demasiado frecuente, entre comillas. Y para lidiar con esto, sacamos nuestro estado de esos componentes. Por ejemplo, redux a distancia y ahora señales sacándolo completamente de React. Creo que esto

se pierde un poco el punto. Y creo que el equipo principal de React podría estar de acuerdo con nosotros. Porque en realidad, ellos crearon una biblioteca de gestión de estado justo cuando crearon React. Esta biblioteca de gestión de estado se llama React. Y cada vez que instalas React a través de NPM, también estás instalando React. Veamos qué hace este React. Si observo mi componente, notaré que hay en realidad dos, más de dos, pero al menos dos preocupaciones que están todas mezcladas dentro de él. Si soy una lista, no me importa cada letra que ingresa en este campo de entrada. Eso no es lo que me preocupa. Y tenerlo en este campo de entrada significa que este campo de entrada se volverá a renderizar con cada letra que ingrese. Parece razonable para React, y ese era el objetivo principal de React, que se volviera a renderizar cada vez que cambia el estado. Así es como reacciona. Eso es a lo que está reaccionando. Son las operaciones de cambio de estado. El mensaje principal de los primeros tiempos de React era que la interfaz de usuario es una función del estado, y eso es lo que forma el componente es, estamos tomando todo el estado y lo estamos agrupando junto con la interfaz de usuario, estamos diciendo que los dos son inseparables. Y lo que hace React es aprovechar esto, aprovecha esta conexión implícita entre los componentes y el árbol de componentes para decir que no necesitamos hablar explícitamente sobre la conexión entre las piezas de estado. El árbol de componentes es esa conexión entre las piezas de estado. Y mientras separemos adecuadamente nuestras preocupaciones, nuestros estados y nuestros componentes, no solo obtendremos una aplicación más eficiente, sino que también obtendremos una aplicación mucho más fácil de leer. Obtendremos componentes que son más pequeños, más rápidos, más ligeros y más legibles. Y eso es lo que encuentro asombrosamente hermoso de React, que si pensamos adecuadamente en nuestras preocupaciones, como deberíamos hacer de todos modos, nuestra aplicación casi siempre será lo suficientemente rápida para manejar lo que queremos hacer. Y si no lo es, entonces supongo que deberías usar Svelte.