SwiftUI Series 07｜Conversão de pensamento de UIKit para SwiftUI

Muitos desenvolvedores UIKit mudam para SwiftUI pela primeira vez. A parte mais dolorosa nem sempre é o que sentem:

• A API obviamente não é complicada
• Mas por que é sempre difícil escrever?

A razão é muitas vezes que o modelo de pensamento subjacente ainda não foi eliminado.

Porque o UIKit está perguntando por padrão:

• Qual visualização desejo criar agora?
• Quando vou atualizá-lo?
• Como faço para mantê-lo manualmente consistente com os dados

SwiftUI é mais como perguntar:

• Qual é o status atual
• Como deve ser a interface neste estado?
• Como a interface deve se reorganizar naturalmente quando o estado muda

Estas duas ideias são que a posição de controlo mudou.

1. A primeira coisa a anotar é “Confio principalmente no meu driver manual para atualizações de interface”

Muitas experiências no UIKit giram em torno disso:

• Quando recarregar
• Quando definirNeedsLayout
• Qual callback para alterar uma determinada subvisualização?

O SwiftUI certamente precisa gerenciar o estado, mas o que ele quer fazer é:

• Gerenciar fontes de status
• Gerenciar limites estaduais
• Como o status de gerenciamento é mapeado para a UI

Em vez de continuar focando em “como faço para atualizar a interface manualmente?”

Caso esse hábito não seja alterado, a situação mais provável de ocorrer posteriormente é:

• SwiftUI parece ser escrito em estilo declarativo
• Mas ainda tenho em mente o driver imperativo do UIKit

No final, o código se tornará uma mistura de dois tipos de pensamento, nem aproveitando o SwiftUI nem perdendo o claro senso de controle do UIKit.

2. A segunda coisa a ser feita é tratar o View como um objeto estável.

Esse é o hábito que os desenvolvedores com experiência em UIKit provavelmente adotarão por padrão.

No UIKit, é natural pensar em uma página ou célula como:

• um objeto criado
• Será atualizado continuamente no futuro

Mas o View do SwiftUI é mais como uma descrição de estado. Não é “um objeto no qual venho trabalhando para mudar há muito tempo”, mas sim “a expressão estrutural da interface em seu estado atual”.

Isso significa que se você sempre começar com “Esta visualização sempre estará lá, eu apenas a altero”, será fácil:

• Julgamento do ciclo de vida
• Local de armazenamento de status
• Ligação de tarefas assíncronas

Armadilhas frequentes sobre essas questões.

3. A terceira coisa a abandonar é a dependência excessiva de patches locais para reparar a IU.

Um caminho muito comum no desenvolvimento do UIKit é:

• Primeiro coloque a vista para fora
• Corrija o que estiver errado
• Se um controle estiver um pouco errado, corrija-o localmente.

Este método não é completamente inutilizável no SwiftUI, mas se você continuar fazendo isso, a página se tornará facilmente:

• Existem muitos modificadores
• Hierarquia estrutural pouco clara
• Um pequeno reparo leva a outra mudança de layout

Porque o SwiftUI incentiva primeiro a expressar a estrutura claramente e, em seguida, anexar modificações locais a ela. Se a própria estrutura for instável, remendos locais irão reparar o problema e quebrá-lo em pedaços.

4. A quarta coisa a mudar é: pensar menos em termos de “controles” e mais em termos de “fluxo de estado”

No pensamento do UIKit, muitas organizações de páginas são centradas no controle:

-O que esta etiqueta mostra?

• Se este botão está desativado
• Quando esse tableView será recarregado?

SwiftUI incentiva a partir do fluxo de estado:

• Qual é o status atual da página?
• Quais fragmentos de UI devem ser mapeados para este estado
• Como o estado evolui após uma ação

Esta mudança é crítica porque afeta diretamente:

• Como projetar ViewModel
• Como desmontar componentes
• Como determinar qual status deve ser compartilhado e qual não deve ser compartilhado

5. A quinta coisa a mudar é: não se apresse em traduzir toda a experiência do UIKit para o método de escrita correspondente do SwiftUI

Quando aprendi este conteúdo sobre SwiftUI, inconscientemente fiz esta pergunta:

• O que isso equivale no UIKit?
• Qual retorno de chamada corresponde a este ciclo de vida
• Este comportamento é equivalente a reloadData?

Esse tipo de mapeamento é útil no início, mas pode causar problemas se for baseado em longo prazo:

• Sempre procurando por uma contraparte do UIKit
• Mas realmente não aceitava que o SwiftUI fosse outra forma de organização

O ponto de viragem que é realmente fácil de usar geralmente é:

Comecei a pensar nas páginas diretamente no reconhecimento de problemas do SwiftUI, em vez de primeiro traduzir de volta para o UIKit e depois tomar decisões.

6. Um método de transição mais prático: não busque uma “mudança cerebral completa imediatamente”, primeiro mude a maneira como você faz algumas perguntas de alta frequência.

O mais útil é primeiro mudar a maneira como você faz estas perguntas:

Coloque:

• Quando atualizo esta visualização?

Alterar para:

• Quais mudanças de estado devem impulsionar esta atualização de área

Coloque:

• Quando esse controle deve ser alterado?

Alterar para:

• Quem deve possuir esse valor?

Coloque:

• Esta página aparece uma ou várias vezes?

Alterar para:

• A que estado ou ciclo de vida esta tarefa deve estar vinculada?

A mudança nessa forma de perguntar pode parecer pequena, mas aos poucos puxará o pensamento padrão em direção ao SwiftUI.

7. Conclusão: A coisa mais importante ao mudar do UIKit para o SwiftUI é reposicionar o pensamento de controle.

Para resumir, eu diria:

Do UIKit para o SwiftUI, o que realmente precisa mudar é de “Vou conduzir a interface manualmente” para “Vou definir o estado e os limites e deixar a interface ser estabelecida de acordo com o estado”.

Assim que isso começar a acontecer, muitas coisas que originalmente pareciam “Por que o SwiftUI é tão estranho?” lentamente se tornará natural.