SwiftUI Series 01｜Os limites aplicáveis ​​do SwiftUI

Quando tive contato com o SwiftUI pela primeira vez, as perguntas mais frequentes foram:

• Pode substituir o UIKit?
• Todos os novos projetos devem usar SwiftUI?
• Vale a pena realocar o projeto antigo?

Estas questões são obviamente importantes, mas se a discussão se centrar na “substituição” desde o início, o julgamento será muitas vezes feito ao extremo. Uma questão mais prática seria:

Que tipo de complexidade de página o SwiftUI consegue lidar melhor e que tipo de problemas ele não necessariamente domina?

Somente se esta questão for respondida claramente primeiro, os subseqüentes “deve ser usado” e “até que ponto” ser usado terão significado prático.

1. O verdadeiro poder do SwiftUI é que ele coloca “como as mudanças de estado são mapeadas nas interfaces” em primeiro lugar

A ideia padrão do UIKit é mais parecida com:

• veja primeiro
• Vá e atualize a visualização novamente
• Em seguida, lide com o relacionamento de sincronização entre vários componentes da UI

A ideia padrão do SwiftUI está mais próxima de:

• Status pré-existente
• Em seguida, descreva “como deve ser a interface neste estado”

Isso significa que é naturalmente mais adequado para páginas onde “a principal complexidade da interface vem da expressão do estado”. Por exemplo:

• Vazio / carregando / carregado / mudança de erro para a página óbvia
• página do formulário
• Página de configurações
• Exibir página de detalhes
• Uma página onde vários widgets são vinculados por um conjunto de status de negócios

É claro que essas páginas podem ser escritas no UIKit, mas muitos relacionamentos de sincronização geralmente precisam ser mantidos manualmente. A vantagem do SwiftUI é justamente facilitar a expressão de tais relacionamentos como um todo.

2. É particularmente adequado para páginas comerciais onde “o status é mais importante do que os detalhes da interação”

A verdadeira dificuldade com muitas páginas de negócios é:

• Qual é a situação atual?
• O que exibir em diferentes estados
• Quais áreas precisam ser alteradas em conjunto após uma determinada ação empresarial?

Por exemplo:

• Centro pessoal
• Página de configurações
• Página de detalhes do artigo
• Página de resultados de pesquisa
• Página de detalhes do pedido

Essas páginas raramente exigem níveis extremos de coordenação de rolagem ou design de gestos, mas envolvem muito:

• Mudança de status
• Exibição condicional
• Combinação de componentes
• Atualização parcial

É nessas coisas que o SwiftUI se torna mais útil.

3. Também é muito adequado para páginas com “iteração rápida e alterações frequentes na interface do usuário”

Isso é muito importante em equipes reais.

Algumas páginas não apresentam alterações frequentes de produtos:

• Revisão de redação
• Mudanças estruturais
• Alterar a ordem dos cartões
• Alterar a condição de exibição de um determinado módulo

Nesses cenários, a vantagem do SwiftUI geralmente não é apenas “menos código”, mas também a menor carga mental de modificar a estrutura da IU. É mais fácil tratar a página como uma árvore de estrutura orientada por estado para modificar, em vez de alternar entre muitas visualizações parciais.

Portanto, se a realidade de uma equipe é que “as páginas mudam com frequência”, o SwiftUI costuma ser muito atraente.

4. Mas o SwiftUI não é naturalmente adequado para todas as “páginas complexas”

Este também é o ponto que mais precisa ficar claro.

Uma situação comum é que ao ouvir “SwiftUI é mais moderno”, você inconscientemente irá equipará-lo a “todas as páginas são mais adequadas”. Mas em projetos reais, a complexidade de páginas complexas vem de fontes diferentes.

Se a dificuldade principal de uma página for:

• Controle de rolagem extremamente fino
• Muita coordenação de gestos de baixo nível
• Tempo de animação muito personalizável
• Controle extremamente exigente sobre detalhes de renderização e interação

Então o SwiftUI pode não ser naturalmente mais fácil.

é:

• Algumas habilidades precisam ser contornadas
• Às vezes você tem que misturar o UIKit
• Alguns comportamentos subjacentes são mais caros para depurar

Portanto, “a página é complexa” não é um critério em si, a chave é onde ela é complexa.

5. Um julgamento mais prático: a dificuldade central da página é “expressão de status” ou “controle subjacente”?

Este é o meu método de julgamento mais comum.

Se a dificuldade principal da página for:

• Como mapear vários estados de negócios para a interface
• Como combinar componentes naturalmente à medida que o estado muda
• Como manter a estrutura da página clara

Então o SwiftUI costuma ser adequado.

Se a dificuldade principal da página for:

• Como controlar com precisão as interações subjacentes
• Como coordenar comportamentos complexos de rolagem
• Como implementar comportamentos de animação e layout não padrão

Esse UIKit tende a ser mais estável, ou pelo menos mais “controlável”.

Este julgamento não é absoluto, mas é bastante prático em projetos reais. Ele pode orientar melhor a seleção diária do que a pergunta “O SwiftUI pode substituir o UIKit?”

6. A estratégia mais realista em projetos antigos geralmente é “misturar de acordo com os limites”

Se o projeto já possui uma estrutura UIKit madura, o problema mais provável é “imaginação de migração ideal demais”.

Em projetos reais, o caminho mais comum e mais estável costuma ser:

• Use o SwiftUI primeiro para novas páginas
• Páginas UIKit estáveis não podem ser facilmente alteradas
• Misture quando necessário
• Não busque a migração completa de uma só vez

Porque os próprios custos de migração são custos empresariais. Se a mudança de framework não trouxer benefícios claros e tiver apenas o propósito de “unificar a pilha”, é provável que o ganho supere a perda.

7. Um mal-entendido comum: tratar o SwiftUI como “uma versão com sintaxe atualizada do UIKit”

Quando aprendi esta parte do SwiftUI, ainda estava fazendo estas perguntas em minha mente:

• Esta visualização é criada apenas uma vez?
• Quando quero atualizar manualmente?
• Não é como o UIKit, onde você só precisa alterá-lo diretamente.

Essas dúvidas são normais, mas se você ficar nesse ponto de vista por muito tempo, será difícil realmente usar bem o SwiftUI. Porque SwiftUI é uma forma completamente diferente de organizar a interface.

Requer priorizar o pensamento sobre:

• Quem é o responsável pelo status?
• Como mapear este estado para UI
• A atualização da interface faz parte do fluxo de estado?

Depois que você ainda usa o pensamento do UIKit, o SwiftUI pode facilmente acabar se tornando “aparentemente declarativo, mas na verdade a lógica é mais confusa”.

8. Conclusão: Se o SwiftUI é adequado ou não, não depende se é novo ou não, mas depende da origem da complexidade da página.

Para resumir, eu diria:

SwiftUI é mais adequado para páginas cuja complexidade principal vem principalmente da expressão de estado, combinação de interface e frequência de iteração; e para aquelas páginas cuja complexidade provém principalmente da interação subjacente e do controle preciso, ela pode não ser naturalmente dominante.

Portanto, o verdadeiro julgamento prático é:

• O que há de tão complicado nesta página?
• O SwiftUI pode atingir esse tipo de complexidade?

Uma vez que esta pergunta seja respondida claramente, a seleção geralmente não é muito confusa.