SwiftUI Series 06 ｜ División de componentes SwiftUI y mantenibilidad del código

Cuando surge el tema de “desmontar componentes”, la primera reacción es:

• Esta vista es demasiado larga
• Dividirlo en varias subvistas.

Este es ciertamente un comienzo, pero si el criterio de división es simplemente “demasiadas líneas de código”, es fácil terminar con otro tipo de confusión:

• De hecho, hay más archivos.
• Pero la relación de estatus es más difícil de entender.
• Los nombres de los componentes son cada vez más abstractos.
• Pasar un montón de parámetros entre padre e hijo.

En otras palabras, la página no es más clara, simplemente cambia de un archivo grande a muchos archivos rotos.

Entonces, la división de componentes verdaderamente efectiva es:

Hacer que los límites de las estructuras, los límites estatales y los límites de reutilización sean más claros al mismo tiempo.

1. Primero distinga: ¿está desmantelando la estructura o reutilizándola?

Es común que se mezclen las dos cosas.

1. Dividir para facilitar la lectura estructural

El propósito es aclarar la jerarquía de páginas actual. Este tipo de división es completamente razonable incluso si se usa sólo una vez en una página.

2. Dividir para reutilizar entre páginas

El objetivo es extraer componentes reutilizables. Este tipo de división requiere límites más estables e interfaces más restringidas.

Si no se distinguen estos dos tipos de finalidades, las consecuencias más habituales son:

• Obviamente solo quería hacer la página más clara, pero terminé extrayéndola prematuramente como un “componente universal”.
• O este patrón se ha repetido muchas veces, pero todavía se considera una subvista parcial.

Por lo tanto, el primer paso en la división de componentes es determinar qué tipo de problema se está resolviendo.

2. La razón por la que muchas páginas se vuelven cada vez más confusas es porque Ver asume demasiados roles.

Una vez que una página asume estas cosas al mismo tiempo, es fácil expandirse rápidamente:

• estructura de diseño
• Estado de la interfaz de usuario local -Mapeo del estado del negocio
• Formato de datos
• Asamblea de acción interactiva.

En este momento, encontrará que el código largo no es la causa principal. El verdadero problema es:

• ¿Qué lógica pertenece a Ver?
• ¿Qué lógica debería haber afuera?
• ¿Qué estructuras locales merecen una expresión independiente?

El valor real de la división de componentes es forzar que se vuelva a realizar este juicio de límites.

3. Lo que más vale la pena eliminar primero suele ser “la pieza con la semántica más completa en la página actual”

Una situación común es que tan pronto como se desmontan los componentes, se apresuran a encontrar la pieza más versátil. Pero en el desarrollo real, un enfoque más estable suele ser desmantelar primero aquellas piezas que están semánticamente completas en la página actual.

Por ejemplo:

• Área de encabezado de datos
• Tarjeta de resumen del artículo
• Establecer fila de elementos
• Bloques vacíos

Los beneficios de estas estructuras son:

• Son originalmente una unidad independiente en la página.
• La semántica estructural será más clara después de ser eliminada.
• Incluso si no lo reutilizas por un tiempo, no perderás dinero

Esto es mucho más estable que intentar crear un “contenedor de células súper universal” desde el principio.

4. Una vez que se eliminan los componentes, la interfaz se convierte en un verdadero problema de diseño.

Uno de los mayores valores de la división de componentes es que te obliga a pensar en interfaces.

Pronto lo descubrirás:

• ¿Este subcomponente debería tomar el modelo original o los datos de visualización formateados?
• Necesita saber cómo saltar después de hacer clic, o solo exponer una acción
• ¿Debería tener un estado local o estar controlado por una capa principal?

Si no desea comprender estos problemas con claridad, el componente puede convertirse fácilmente en:

• Muchos parámetros
• Semántica empresarial poco clara
• La capa principal necesita saberlo todo.

Entonces, la división de componentes es un trabajo de diseño de interfaz.

5. Un mal olor muy común: mezclar “división parcial de la estructura” y “división de la lógica empresarial”

Por ejemplo, si se elimina una tarjeta de lista, también será responsable de:

• Visualización de diseño
• Formato de datos
• enterrar el punto
• Juicio empresarial después del clic.

Aunque este componente es independiente, sus responsabilidades siguen siendo mixtas.

Un enfoque más estable suele ser:

• Los componentes de la pantalla deben centrarse en la pantalla tanto como sea posible.
• Mantener las decisiones comerciales en niveles superiores tanto como sea posible.
• Los subcomponentes exponen los eventos necesarios sin absorber directamente todo el proceso de negocio.

De lo contrario, cuantos más componentes se desmantelen, más fragmentada estará la lógica, pero la complejidad no disminuirá.

6. ¿Cuándo no debería apresurarse a fumar “componentes generales”?

Este es el punto en el que muchos proyectos de SwiftUI pueden sobrediseñarse fácilmente.

Si un patrón aparece actualmente solo una vez en una página, y:

• La estructura empresarial aún no es estable
• Los detalles de la interfaz de usuario siguen cambiando rápidamente
• Todavía no estoy seguro de los límites.

En este momento, es más apropiado dividirlo en subvistas locales dentro de la página en lugar de actualizarlo inmediatamente a un componente general.

Porque la “reutilización prematura” suele tener una consecuencia:

• La interfaz del componente se vuelve muy amplia.
• Para ser compatible con posibles escenarios futuros, primero se incluyen muchas opciones

El resultado es que es más difícil mantenerlo que no desmontarlo.

7. Un juicio práctico: si esta subestructura se elimina sola, ¿pueden otros decir qué es?

Esta es una forma muy común para mí de juzgar.

Si se elimina una determinada subestructura, naturalmente todos pueden decir:

• Este es un encabezado de perfil de usuario.
• Esta es una fila de configuración.
• Esta es una tarjeta de resumen del artículo.

Entonces suele ser adecuado para el desmontaje.

Si lo sacas, solo puedes decir:

• Este es un “contenedor combinado”
• Esta es una “Vista de bloque de contenido”
• Este es un “estuche para cartas multiescena”

Lo más probable es que eso signifique que su semántica no es lo suficientemente estable y que es posible que aún no haya llegado el momento de la división.

8. Conclusión: Lo que realmente se persigue con la división de componentes es tener límites más claros.

Para decirlo en forma más breve, diría:

El estándar verdaderamente efectivo para dividir componentes de SwiftUI es que después de la división, los límites de la estructura, los límites de los estados y los límites de la interfaz son más claros que antes.

Sólo así los componentes se volverán más ligeros a medida que se vayan desmontando; de lo contrario, fácilmente se convertirán en más archivos y el sistema será más difícil de leer.