Todos sabemos que separar las preocupaciones es diferente de separar las tecnologías. Eso es de lo que se trata React. Pero, ¿qué es una preocupación? ¿Qué significa separarlas? ¿Por qué debería preocuparme por las preocupaciones o la separación?
Separando la Separación de Preocupaciones
Video Summary and Transcription
Mi preocupación es lograr mi comprensión de mi preocupación. Una aplicación de tareas pendientes puede tener más que solo administrar tareas. Las preocupaciones transversales deben estar ubicadas en el mismo lugar. La separación de preocupaciones es una técnica efectiva para ordenar los pensamientos. React no es más lento que JS. React puede estar más cerca de una biblioteca con la preocupación de la programación. Volver a renderizar los componentes con demasiada frecuencia es un problema en React. React es una biblioteca de gestión de estado que ayuda a separar las preocupaciones y los estados, lo que resulta en una aplicación más eficiente y legible. La separación adecuada de preocupaciones, estados y componentes conduce a componentes más pequeños, más rápidos, más ligeros y más legibles.
1. Preocupaciones en React y Separación de Preocupaciones
Mi preocupación es lograr mi comprensión de mi preocupación. Una aplicación de tareas pendientes puede tener más que solo administrar tareas. Las preocupaciones transversales deben estar ubicadas en el mismo lugar. La separación de preocupaciones es una técnica efectiva para ordenar los pensamientos. React no es más lento que JS. React puede estar más cerca de una biblioteca con una preocupación de programación. Volver a renderizar los componentes con demasiada frecuencia es un problema en React.
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
2. React State Management and Separation of Concerns
React es una biblioteca de gestión de estado que se incluye con React mismo. Ayuda a separar las preocupaciones y los estados, lo que resulta en una aplicación más eficiente y legible. Al aprovechar la conexión implícita entre los componentes y el árbol de componentes, podemos evitar hablar explícitamente sobre la conexión entre las piezas de estado. La separación adecuada de preocupaciones, estados y componentes conduce a componentes más pequeños, más rápidos, más ligeros y más legibles.