SwiftUI Serie 07 ｜ Conversión de pensamiento de UIKit a SwiftUI

Muchos desarrolladores de UIKit cambian a SwiftUI por primera vez. La parte más dolorosa no siempre es que sientan:

• La API obviamente no es complicada.
• ¿Pero por qué siempre es difícil escribir?

La razón suele ser que el modelo de pensamiento subyacente aún no ha sido eliminado.

Porque UIKit pregunta de forma predeterminada:

• ¿Qué vista quiero crear ahora?
• ¿Cuándo lo actualizaré?
• ¿Cómo puedo mantener manualmente la coherencia con los datos?

SwiftUI es más como preguntar:

• ¿Cuál es el estado actual?
• ¿Cómo debería verse la interfaz en este estado?
• Cómo la interfaz debería reorganizarse naturalmente cuando cambia el estado.

Estas dos ideas son que la posición de control ha cambiado.

1. Lo primero que debo escribir es “Confío principalmente en mi controlador manual para las actualizaciones de la interfaz”.

Muchas experiencias en UIKit giran en torno a esto:

• Cuando recargar
• Cuándo configurarNeedsLayout
• ¿Qué devolución de llamada para cambiar una determinada subvista?

SwiftUI ciertamente necesita administrar el estado, pero lo que quiere hacer es:

• Administrar fuentes de estado
• Gestionar las fronteras estatales
• Cómo se asigna el estado de gestión a la interfaz de usuario

En lugar de seguir centrándose en “¿cómo actualizo la interfaz manualmente?”

Si no se cambia este hábito, la situación más probable que se presente más adelante es:

• SwiftUI parece estar escrito en un estilo declarativo.
• Pero todavía tengo en mente el controlador imperativo de UIKit.

Al final, el código se convertirá en una mezcla de dos tipos de pensamiento, sin aprovechar SwiftUI ni perder la clara sensación de control de UIKit.

2. Lo segundo que hay que dejar es tratar la Vista como un objeto estable.

Este es el hábito que los desarrolladores con experiencia en UIKit probablemente adopten de forma predeterminada.

En UIKit, es natural pensar en una página o celda como:

• un objeto creado
• Se actualizará continuamente en el futuro.

Pero el View de SwiftUI se parece más a una descripción de estado. No es “un objeto en el que he estado trabajando para cambiar durante mucho tiempo”, sino más bien “la expresión estructural de la interfaz en su estado actual”.

Esto significa que si siempre comienzas desde “Esta vista siempre estará ahí, sigo cambiándola”, será fácil:

• Juicio del ciclo de vida.
• Ubicación de almacenamiento de estado
• Enlace de tareas asincrónicas

Errores frecuentes en estos temas.

3. La tercera cosa que debemos dejar de lado es la excesiva dependencia de los parches locales para reparar la interfaz de usuario.

Un camino muy común en el desarrollo de UIKit es:

• Primero apaga la vista.
• Corregir lo que esté mal.
• Si un control está un poco apagado, parcheelo localmente.

Este método no es completamente inutilizable en SwiftUI, pero si continúas haciéndolo, la página fácilmente se convertirá en:

• Hay muchos modificadores.
• Jerarquía estructural poco clara
• Una reparación menor conduce a otro cambio de diseño.

Porque SwiftUI recomienda expresar la estructura con claridad primero y luego adjuntarle modificaciones locales. Si la estructura en sí es inestable, los parches locales repararán el problema y lo romperán en pedazos.

4. La cuarta cosa a cambiar es: pensar menos en términos de “controles” y más en términos de “flujo de estados”

En el pensamiento de UIKit, muchas organizaciones de páginas se centran en el control:

-¿Qué muestra esta etiqueta?

• Si este botón está deshabilitado
• ¿Cuándo se recargará este tableView?

SwiftUI recomienda comenzar desde el flujo de estado:

• ¿Cuál es el estado actual de la página?
• Qué fragmentos de la interfaz de usuario deben asignarse a este estado
• Cómo evoluciona el estado después de una acción.

Este cambio es crítico porque afecta directamente:

• Cómo diseñar ViewModel
• Cómo desmontar componentes.
• Cómo determinar qué estado se debe compartir y cuál no se debe compartir

5. El quinto cambio es: no se apresure a traducir toda la experiencia de UIKit al método de escritura correspondiente de SwiftUI.

Cuando descubrí por primera vez este contenido sobre SwiftUI, inconscientemente hacía esta pregunta:

• ¿A qué equivale esto en UIKit?
• Qué devolución de llamada corresponde a este ciclo de vida.
• ¿Este comportamiento es equivalente a reloadData?

Este tipo de mapeo es útil al comenzar, pero puede causar un problema si se utiliza a largo plazo:

• Siempre buscando una contraparte de UIKit
• Pero realmente no acepté que SwiftUI sea otra forma de organización.

El punto de inflexión que es realmente fácil de utilizar suele ser:

Comencé a pensar en páginas directamente en la conciencia de problemas de SwiftUI, en lugar de volver a traducirlas a UIKit primero y luego tomar decisiones.

6. Un método de transición más práctico: no busque un “cambio cerebral completo de inmediato”, primero cambie la forma en que hace algunas preguntas de alta frecuencia.

Lo más útil es cambiar primero la forma de hacer estas preguntas:

Poner:

• ¿Cuándo actualizo esta vista?

Cambiar a:

• ¿Qué cambios de estado deberían impulsar la actualización de esta área?

Poner:

• ¿Cuándo se debe cambiar este control?

Cambiar a:

• ¿Quién debería poseer este valor?

Poner:

• ¿Esta página aparece una o varias veces?

Cambiar a:

• ¿A qué estado o ciclo de vida debería estar ligada esta tarea?

El cambio en esta forma de preguntar puede parecer pequeño, pero poco a poco llevará el pensamiento predeterminado hacia SwiftUI.

7. Conclusión: Lo más importante al pasar de UIKit a SwiftUI es reposicionar la idea de control.

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

De UIKit a SwiftUI, lo que realmente necesita cambiar es de “Manejaré la interfaz manualmente” a “Definiré el estado y los límites, y dejaré que la interfaz se establezca de acuerdo con el estado”.

Una vez que esto comienza a suceder, muchas cosas que originalmente parecían como “¿Por qué SwiftUI es tan incómodo?” poco a poco se volverá natural.