Eu estaria discutindo dois poços nos quais você pode cair ao usar o angularjs com o roteador de IU e como você pode se puxar de volta, ou melhor ainda, evitar o poço completamente em primeiro lugar.
Este texto é destinado a desenvolvedores que escrevem / pretendem escrever aplicativos de página única, mas pode, é claro, ser aplicado em outros cenários também
Lidar com a autenticação ao acessar o URL do seu aplicativo no navegador
Você provavelmente deve ter tido sua cota de dor de cabeça para descobrir como lidar adequadamente com esse problema. Dê uma olhada neste cenário: O usuário acessa a URL, você deseja verificar se ele já possui um token de autenticação e, provavelmente, verificar se o token ainda é válido antes de renderizar a página solicitada. É claro que, nesse ponto, seu aplicativo ainda está sem estado, então o rastreamento de estado é impossível. E as coisas podem até piorar se seu aplicativo tiver vários estados compartilhando o mesmo URL (voltaremos a isso em breve) <br/>
No meu caso, tentei o seguinte: altere o hash de local para temporário, renderize uma tela de espera, verifique o token, configure umstateChangeStartouvinte e redirecionar de volta para o local inicial que foi solicitado. O stateChangeStart aqui ajuda a tratar adequadamente as rotas com acesso privilegiado. Infelizmente, manipular o hash de localização dessa maneira resultou em um loop infinito (pouparei os detalhes). No entanto, foi resultado da inexistência de temp. localização, o gatilho do roteador de url e o stateChangeStartpróprio ouvinte. <br/>
Ok, a solução era redirecionar para um temp. em vez disso (com o estado agora mapeado para o local temporário) e envolva o ouvinte stateChangeStart em uma função $ timeout. Isso tem 2 vantagens: qualquer URL que o estado tem agora existe (evitando o acionador de outra forma), e usar o $ timeout garante que todos os processos de verificação realmente concluídos antes de ouvir a mudança de estado comece, consequentemente resolvendo o problema de autenticação e evitando simultaneamente o loop como bem.
Lidar com vários estados com o mesmo URL
Você provavelmente teria considerado isso para um aplicativo em que alguns usuários têm mais permissão do que outros, por exemplo, um URL para proprietários de páginas e visualizadores de páginas, embora tendo o mesmo URL deva, no entanto, fornecer diferentes conjuntos de funções, renderizar visualizações diferentes, etc. que a manipulação CSS comum não resolverá todos os casos. <br/>
De qualquer forma, é simples: rotear para aquela URL sempre dispara o primeiro estado eventualmente, tornando o segundo estado inacessível de qualquer forma. Você poderia ser muito inteligente e executar explicitamente um para o segundo estado, mas isso aconteceria: (ativação do estado, atualizações de localização) nessa ordem. Agora, após a atualização do local, o estado é novamente retornado ao primeiro. Triste! <br/> A correção era para o primeiro estado em vez disso, resolver$state.go$state.goo nível de acesso do usuário e enviá-lo para o segundo estado (se ele tiver privilégios suficientes). Usar a resolução aqui garante que a visualização apropriada seja determinada antes de realmente renderizá-la. O problema é que a elevação é sempre a melhor escolha para o rebaixamento! 🙂