SwiftUI Série 05 ｜ Uso correto de NavigationStack e salto de página

Ao usar NavigationStack pela primeira vez, você pensará que é a versão SwiftUI do contêiner de navegação:

• Clique
• empurrar uma página
• É basicamente isso

Mas em projetos reais, a parte realmente problemática da navegação é sempre:

• A página irá pular
• Se o status do salto e o status do negócio são consistentes
• Se o caminho ainda pode permanecer correto ao criar links diretos, retornar e entrar novamente na página

Em outras palavras, o que o NavigationStack realmente precisa lidar não é apenas a troca de interface, mas o próprio estado de navegação.

1. Os problemas de navegação de muitos projetos no passado vieram essencialmente de “ações de salto espalhadas por toda parte”

Na era UIKit, uma forma muito comum de escrever é:

• Pressione diretamente em um botão
• Apresentar diretamente em um retorno de chamada
• Quando um ViewModel chama de volta, ele passa pelo delegado

Claro que funcionará no curto prazo, mas o problema é que a lógica de navegação ficará cada vez mais dispersa. Difícil de responder:

• Por que você está nesta página?
• Para qual estado você deve retornar após retornar?
• Após a conclusão de um determinado negócio, ele saltará para dois níveis.

O NavigationStack do SwiftUI oferece uma chance melhor: Altere o “caminho de navegação atual” de ação implícita para estado explícito.

2. A coisa mais importante sobre NavigationStack é o caminho

Quando aprendi este conteúdo NavigationStack, apenas olhei para:

-NavigationLink -navigationDestination

Claro que você precisa saber disso, mas o que realmente deve ser entendido primeiro é:

A navegação pode ser expressa como um caminho de estado no SwiftUI.

Isso significa não mais apenas “pular ao clicar”, mas manter:

• Quais páginas estão no caminho atual?
• Qual status comercial corresponde a qual destino
• Como o caminho deve mudar após uma determinada operação?

Uma vez vista dessa perspectiva, a navegação deixa de ser apenas um evento de UI e passa a fazer parte do fluxo de estado.

3. Muitas navegações são confusas porque o status do negócio e o status do roteamento não estão alinhados.

Para dar um exemplo muito comum:

• O usuário seleciona um artigo
• A página de detalhes do artigo deve aparecer
• Como sair da página de detalhes após excluir um artigo?

Se você entender a navegação apenas como “clique para entrar”, muitas perguntas subsequentes começarão a ficar confusas:

• Como restaurar o caminho quando um link direto chega
• Como ajustar o caminho após falha de dados
• Em que estado a lista deve permanecer quando for devolvida

Portanto, o que é realmente difícil na navegação é que ela não deveria existir independentemente do estado empresarial.

Uma ideia mais estável é:

• O caminho de navegação e o status do negócio são mutuamente interpretáveis
• O motivo pelo qual você está nesta página pode ser explicado claramente no status.

4. NavigationLink é muito conveniente, mas como o projeto é complexo, você não pode confiar nele para expressar toda a navegação

NavigationLink é particularmente adequado para saltos diretos, parciais e simples, tais como:

• Clique na lista para detalhes
• Definir configurações de feed de página

Mas se o projeto for complexo, se toda a navegação depender de NavigationLink disperso, você logo encontrará:

• Os caminhos são difíceis de gerenciar uniformemente
• Links diretos são difíceis de acessar
• Certos saltos no processo não são mais simplesmente acionados por cliques.
• O caminho de retorno está desconectado do status do negócio

É por isso que é mais adequado para assumir entradas locais e não é adequado para realizar apenas a estratégia de navegação de toda a aplicação.

5. Uma ideia mais prática: projetar o “destino da página” como um valor que pode ser explicado pelo negócio

Uma das causas principais de muitos acidentes de navegação em projetos é:

• Os saltos são escritos apenas como um monte de ações da interface do usuário
• Nenhum modelo de destino razoável é formado

Um método mais estável geralmente é deixar o caminho levar “para qual destino a empresa atual deseja ir”.

Por exemplo:

• artigoDetalhe(id: String)
• perfil do usuário (id: String)
• configurações

Dessa forma, a navegação parece mais com estados do que com uma coleção desarticulada de ações. Seus benefícios são:

• Caminhos podem ser reconstruídos
• Links diretos são mais naturais
• Teste e depuração também são mais fáceis de descrever

6. O mau cheiro mais comum em projetos reais: View, ViewModel e ações de roteamento estão interligadas

Muitos códigos de navegação do SwiftUI ficam assim:

• Escreva parte do NavigationLink no View
• O ViewModel decidiu secretamente pular novamente
• Um determinado retorno de chamada de serviço aciona uma mudança no estado de navegação

No final, ninguém pode dizer claramente:

• Quem é o verdadeiro dono da navegação
• Qual estado determina o caminho atual
• Uma determinada ação de retorno é um comportamento do usuário ou um comportamento empresarial?

Assim que a navegação entrar nesse estado, o custo de adicionar um link direto ou de adicionar um caminho de recuperação aumentará significativamente.

7. Um julgamento prático: a página atual é “porque cliquei” ou “porque o status determina que ela deveria estar aqui”

Isso é algo que muitas vezes me pergunto.

Se uma página aparecer, ela só poderá ser interpretada como:

• Porque acabei de clicar em um botão

Isso geralmente significa que a navegação ainda é muito orientada para a ação.

Uma explicação mais ideal deveria ser:

• porque o estado do caminho atual o contém
• porque o contexto comercial atual determina que ele deve ser exibido

Essa diferença é importante. O primeiro é mais como uma ação temporária, o último é mais como um estado de navegação sustentável.

8. Conclusão: O que o NavigationStack realmente permite gerenciar não são apenas saltos, mas o status do caminho.

Para resumir, eu diria:

NavigationStack O que é realmente importante é que ele permite que a navegação seja fechada de forma mais natural, desde “ações de cliques dispersos” até “estado de caminho gerenciável”.

Portanto, a maneira correta de abrir o salto de página não é apenas escrever NavigationLink, mas permitir que o status de navegação e o status comercial se expliquem. Só assim a navegação não se tornará cada vez mais confusa à medida que o projeto se torna mais complexo.