Refatore uma tela sem alterar seu comportamento

Este caso de uso se aplica quando um único arquivo SwiftUI concentra todo o código de uma tela enorme e até uma pequena edição parece arriscada. O objetivo não é redesenhar o recurso nem criar uma nova arquitetura. Peça ao Codex que preserve o comportamento e o layout ao dividir a tela em subviews pequenas, com fluxo de dados explícito. Assim, a próxima alteração será mais fácil de revisar.

Use o plugin Build iOS Apps para esse tipo de refatoração. A habilidade de refatoração de views SwiftUI adota diretrizes práticas. Por padrão, prefira MV a MVVM, mantenha a lógica de negócio em serviços ou modelos, priorize o estado local da view e as dependências do ambiente e só mantenha um modelo de apresentação quando o recurso claramente precisar dele.

O que pedir ao Codex

Comece indicando o arquivo de uma tela específica e peça ao Codex que melhore a estrutura sem alterar o comportamento. Inclua estas regras de refatoração diretamente no prompt:

• Organize o arquivo para facilitar a leitura de cima para baixo. Comece pelas dependências do ambiente, seguidas das propriedades armazenadas, das propriedades computadas que representam estado e não retornam views, de init, de body, dos auxiliares de view e dos métodos auxiliares.
• Extraia seções que façam sentido por si só para tipos View próprios, com um conjunto pequeno de entradas explícitas, vínculos via @Binding e callbacks.
• Use poucas propriedades computadas auxiliares do tipo some View e mantenha cada uma pequena. Evite recriar a tela enorme como uma longa lista de propriedades computadas privadas que retornam fragmentos de view.
• Tire de body as ações de botão mais complexas e os efeitos colaterais. Mova a lógica de negócio propriamente dita para serviços ou modelos.
• Mantenha estável a árvore da view raiz. Prefira condicionais dentro das seções ou nos modificadores a ramificações if/else no nível superior que substituem telas inteiras.
• Ao refatorar, corrija também a forma como as views assumem a responsabilidade pelos modelos que usam Observation. No iOS 17 ou posterior, a view responsável por um modelo raiz @Observable deve armazená-lo em @State. Use os wrappers antigos de observação apenas quando a versão mínima do iOS que o aplicativo precisa suportar exigir isso.

Peça uma validação rápida a cada etapa

Uma refatoração que preserva o comportamento deve incluir uma verificação que comprove isso. Peça ao Codex que, após cada extração significativa, faça a menor verificação que permita validar a tela, seja uma compilação, uma prévia, um teste ou uma verificação no simulador. Em seguida, peça que resuma o que mudou na estrutura e o que foi mantido de propósito.

Dicas práticas

Divida a tela antes de discutir a arquitetura

Se a tela estiver grande demais, peça ao Codex que extraia as seções para views próprias antes de introduzir uma nova camada de abstração. Com uma árvore de views mais enxuta e explícita, muitas vezes já não há motivo para adicionar um modelo de apresentação.

Passe a menor interface possível para cada subview

Prefira valores declarados com let, vínculos via @Binding e callbacks com uma única finalidade a passar o modelo inteiro da view pai para cada view filha. Assim, fica mais fácil visualizar cada seção extraída em uma prévia e mais difícil acoplá-la de novo, por acidente, à tela inteira.

Peça ao Codex que destaque o que preservou de propósito

Para refatorar com segurança, peça ao Codex que liste explicitamente o que manteve intacto, como as regras de negócio, o comportamento da navegação, a persistência, o significado dos dados de análise e o layout que o usuário vê. Isso agiliza bastante a revisão.