The Composable Architecture de Point-Free: State, Action, Reducer, Effect y Store; composición, @Dependency, navegación como dato y testing exhaustivo.
Cada nivel construye sobre el anterior. Sin saltos, sin huecos.
La visión aérea de The Composable Architecture: State, Action, Reducer, Effect y Store; composición, dependencias y testing exhaustivo.
The Composable Architecture: el Elm/Redux de Swift por Point-Free; flujo unidireccional para SwiftUI.
El reducer de TCA: una función pura de estado y acción que devuelve efectos; Effect para lo asíncrono.
La C de Composable: componer reducers, la inyección de dependencias, y el testing exhaustivo con TestStore.
Las piezas del lenguaje que TCA explota: structs y enums como valores, protocolos, y las macros de Swift 5.9+.
Cómo `@Reducer` genera el andamiaje: el enum de acciones, los conformances, y qué escribe realmente por ti.
La observación moderna: `@ObservableState` sobre el Observation framework; SwiftUI solo redibuja lo que cambió.
Diseñar el State: structs anidadas, hacer imposibles los estados inválidos, y qué NO debe vivir en el estado.
Diseñar las acciones: eventos de usuario vs respuestas del sistema, acciones anidadas, y BindableAction.
El `body`: componer con `Reduce`, el orden de ejecución de los operadores, y `_printChanges` para depurar.
Los efectos: `.run` con async/await, `.send` desde dentro, `.none`, y por qué el efecto es un valor devuelto y no un side effect.
Controlar el tiempo: `.cancellable`, cancelar por id, debounce de búsquedas, y evitar respuestas obsoletas.
swift-dependencies: `@Dependency`, el DependencyValues, y por qué sustituir el reloj y la red cambia el testing.
Definir tu propia dependencia: `DependencyKey`, los valores liveValue/testValue/previewValue, y `@DependencyClient`.
Conectar un reducer hijo dentro del padre con `Scope`; el key path del estado y el case path de la acción.
Listas de features: `IdentifiedArray`, el operador `forEach`, y acciones dirigidas a un elemento por id.
Features opcionales: `ifLet` para estado opcional y `ifCaseLet` para un enum de destinos; el ciclo de vida del hijo.
La idea central: la navegación es estado, no imperativo; modelar a dónde estás como un valor del dominio.
Presentación basada en estado: `@Presents`, `PresentationAction`, y conectar sheets, alertas y diálogos de confirmación.
Pilas de navegación: `StackState` y `StackAction`, empujar y sacar pantallas, y el deep linking como estado inicial.
Conectar controles de SwiftUI: `@Bindable`, `BindingReducer`, y formularios sin escribir una acción por campo.
El TestStore: afirmar CADA cambio de estado y CADA efecto; si algo cambia y no lo declaras, el test falla.
Testear lo asíncrono: relojes controlados (`TestClock`), avanzar el tiempo a mano, y testear debounce y timers.
Cuando el testing exhaustivo estorba: `exhaustivity = .off`, tests de integración de varias features, y el equilibrio.
La herramienta `@Shared`: compartir estado entre features sin duplicarlo, con semántica de valor y testeable.
Persistir con `@Shared`: appStorage, fileStorage, estrategias propias, y el estado que sobrevive al cierre de la app.
Arquitectura a escala: una feature por módulo SPM, tiempos de compilación, previews aislados y fronteras claras.
Usar TCA desde UIKit: observar el store, actualizar la vista imperativa, y migrar pantalla a pantalla.
El coste de TCA: observación granular, evitar recomputar, el tamaño del State, y medir con Instruments.
Adoptar TCA sin reescribir: empezar por una pantalla, convivir con MVVM, y la estrategia incremental.
TCA frente a MVVM con @Observable y otras arquitecturas: qué gana, qué cuesta, y cuándo NO usar TCA.
La síntesis: arquitectar una app completa con TCA, el ecosistema Point-Free, y llevarse las ideas a cualquier plataforma.
Empieza por los fundamentos y sube nivel a nivel hasta el dominio total.
Comenzar el camino →