SwiftUI Série 02｜Introdução ao sistema de layout SwiftUI: VStack, HStack, ZStack, Spacer e frame

Quando aprendi este conteúdo pela primeira vez, foi mais fácil cair em um estado ao projetar o layout do SwiftUI:

• VStack eu posso
• HStack eu também vou
• Spacer parece entender
• frame também escreve com frequência

Mas à medida que a página se torna mais complexa, estes problemas familiares começam a aparecer:

• Esta visualização não está completa
• Adicionado frame mas ainda não alinhado
• Spacer Assim que for colocado, excluirá outras coisas.
• Após vários níveis de aninhamento, a página “não consegue dizer o que está errado, mas não parece certo”

Isso mostra que muitas vezes não entendemos realmente o que o layout SwiftUI está fazendo.

1. A coisa mais importante sobre o layout SwiftUI é o processo de negociação de tamanho

Se você entender layout apenas como “qual pilha usar para colocar os elementos”, logo ficará preso. Porque o verdadeiro núcleo do layout do SwiftUI é um processo de negociação de tamanho, que pode ser entendido aproximadamente como:

1. A supervisão fornece um espaço disponível ou tamanho proposto
2. A subvisão decide o tamanho que deseja ter com base nesta proposta
3. O contêiner pai organiza o layout de acordo com o tamanho retornado pela subvisualização.

Ou seja, o layout é uma negociação constante entre pai e filho.

Uma vez compreendida esta premissa, muitas questões aparentemente metafísicas tornam-se claras:

• Alguns frame são apenas cobertos por uma concha
• Text e Spacer se comportam de maneira muito diferente quando colocados juntos
• Algumas questões de alinhamento são essencialmente compensadas durante a fase de proposta de dimensão.

2. VStack, HStack, ZStack A verdadeira diferença é “quem está liderando qual lógica de posicionamento”

Na superfície:

• VStack Organizado verticalmente
• HStack organizado horizontalmente
• Linhas empilhadas ZStack

Isso certamente é verdade, mas se você apenas se lembrar disso, ainda ficará confuso ao encontrar layouts complexos.

Uma compreensão mais prática é:

• VStack organiza principalmente subelementos verticalmente
• HStack organiza principalmente subelementos horizontalmente
• ZStack empilha principalmente vários elementos na mesma área

O ponto chave é pensar com clareza:

• Qual é o eixo central da página atual?
• Qual camada é responsável pelo layout principal -Qual camada é apenas alinhamento e decoração local

Muitos layouts são escritos de maneira confusa e os níveis primário e secundário não são claramente diferenciados.

3. O valor de Spacer está “consumindo o espaço restante”

Ao usar o Spacer pela primeira vez, você o entenderá intuitivamente como “adicionar uma caixa vazia”.

Isso pode levar a muito uso indevido.

Mais precisamente, o que Spacer faz é:

Ocupar o máximo de espaço restante possível na direção do eixo principal do contêiner atual.

Por exemplo, em HStack, ele consome o espaço horizontal; em VStack, ele consome o espaço vertical.

Uma vez entendido desta forma, fica mais fácil julgar:

-É necessário ter um espaçamento fixo ou alocar espaço restante?

• Deve-se usar padding ou Spacer aqui?
• Spacer Se colocado na posição errada, o centro de gravidade de todo o layout será deslocado.

Muitas páginas “parecem um pouco piores” porque Spacer é usado onde restrições fixas deveriam ser usadas. Como resultado, o layout é alterado silenciosamente pela lógica de alocação de espaço restante.

4. frame é mais facilmente mal compreendido: não é necessariamente “modificar o tamanho do conteúdo”, em muitos casos apenas envolve uma camada de caixas de layout

Este é um dos pontos mais fáceis para os iniciantes do SwiftUI ficarem presos.

Uma situação comum é escrever:

Text("Hello")
  .frame(maxWidth: .infinity)

Pensei que estava alongando Text. Para ser mais preciso, em muitos casos, uma área de layout maior é fornecida fora do Text, em vez de alterar o tamanho do conteúdo interno do próprio Text.

Isso explica muitas confusões comuns:

• Parece mais largo, mas o texto ainda não está alinhado onde eu quero.
• Basta usá-lo com alignment
• O mesmo frame tem efeitos diferentes em visualizações diferentes

Portanto, a chave para frame não é “alterar o tamanho”, mas “quais limites de layout são adicionados à visualização”.

5. A verdadeira causa raiz de muitos problemas de layout é que a “camada de layout principal” e a “camada de modificação local” estão misturadas

Vejamos um antipadrão muito comum:

• Uma camada externa VStack
• Existem várias camadas dentro do HStack
• Adicione frame a cada camada
• Misture mais um pouco Spacer
• Por fim, conte com padding para repará-lo até que você possa vê-lo.

Esse tipo de método de escrita certamente pode produzir resultados a curto prazo, mas assim que você alterar o comprimento da cópia, a largura da tela ou a fonte dinâmica, o layout começará a mudar.

A raiz do problema costuma ser:

• Qual camada é responsável pela estrutura principal
• Qual camada é responsável pelo alinhamento local -Qual camada é apenas uma modificação visual?

Não há camadas.

Uma vez que o layout perca seu senso de hierarquia, ele passará a “depender de um monte de modificadores para puxar temporariamente a posição” em vez de depender da estrutura a ser estabelecida naturalmente.

6. Uma forma mais prática de pensar em layout: primeiro determine o eixo principal, depois determine o espaço restante e depois determine o alinhamento local

Se eu quiser construir uma página um pouco mais complexa hoje, normalmente penso nesta ordem:

1. Esta área é dominada horizontalmente ou verticalmente?
2. A quem deve deixar o espaço restante?
3. Quais locais requerem espaçamento fixo e quais locais requerem espaço flexível.
4. Quais áreas estão alinhadas apenas localmente e não devem afetar a estrutura global.

Esta ordem pode reduzir significativamente a situação de “mais reparos e mais caos”. Porque obriga você a decidir primeiro a estrutura e depois decidir a modificação, em vez de apenas confiar no modificador para acumular os resultados.

7. Muitas páginas do SwiftUI “sempre parecem um pouco piores”

Muitos problemas de página são, na verdade, causados por uma expressão insuficientemente clara da estrutura.

As manifestações comuns incluem:

• A relação entre os blocos de informação não é suficientemente estável
• Enquanto o texto for longo, irá excluir outras coisas.
• O mesmo cartão tem proporções estranhas em telas diferentes

Essas perguntas são frequentemente:

• A lógica de alocação de espaço não é clara
• O eixo principal do layout e as modificações locais são misturados
• O local fixo não é fixo
• A flexibilidade foi anotada novamente

Portanto, aprender verdadeiramente o layout é aprender a julgar como o espaço deve ser alocado.

8. Conclusão: O que você realmente precisa aprender ao começar a usar o layout SwiftUI é a negociação de espaço em vez de nomes de controle.

Para resumir, eu diria:

O que você realmente precisa dominar sobre o layout do SwiftUI é como a visualização pai propõe o tamanho, como a subvisualização responde ao tamanho e como o contêiner é colocado com base nesses resultados.

Uma vez estabelecida esta relação básica, muitas questões de layout passarão de “metafísicas” para “razoáveis”.