Modificar URL da barra de endereços no aplicativo AJAX para corresponder ao estado atual

Eu estou escrevendo um aplicativo AJAX, mas como o usuário se move através do aplicativo, eu gostaria que o URL na barra de endereços para atualizar, apesar da falta de recargas de página. Basicamente, eu gostaria que eles pudessem marcar em qualquer ponto e, assim, retornar ao estado atual.

Como as pessoas lidam com a manutenção do RESTfulness em aplicativos AJAX?

A maneira de fazer isso é manipular location.hash quando as atualizações do AJAX resultarem em uma mudança de estado que você gostaria de ter um URL discreto. Por exemplo, se o URL da sua página for:

http://example.com/

Se uma function do lado do cliente executasse este código:

 // AJAX code to display the "foo" state goes here. location.hash = 'foo'; 

Em seguida, o URL exibido no navegador seria atualizado para:

http://example.com/#foo

Isso permite que os usuários marquem o estado “foo” da página e usem o histórico do navegador para navegar entre os estados.

Com esse mecanismo em vigor, você precisará analisar a parte hash da URL no lado do cliente usando JavaScript para criar e exibir o estado inicial apropriado, pois os identificadores de fragment (a parte após o #) não são enviados para o servidor.

O plug-in hashchange de Ben Alman torna o último uma brisa se você estiver usando o jQuery.

Olhe para sites como book.cakephp.org. Este site altera o URL sem usar o hash e usar o AJAX. Eu não tenho certeza de como isso acontece, mas eu tenho tentado descobrir isso. Se alguém souber, me avise.

Também github.com ao olhar para uma navegação dentro de um determinado projeto.

É improvável que o escritor queira recarregar ou redirect seu visitante ao usar o Ajax. Mas por que não usar o pushState / pushState do HTML5?

Você poderá modificar a barra de endereços o quanto quiser. Obtenha URLs com aparência natural, com AJAX.

Confira o código no meu último projeto: http://iesus.se/

Isso é semelhante ao que Kevin disse. Você pode ter seu estado de cliente como algum object javascript e, quando quiser salvar o estado, serializar o object (usando codificação JSON e base64). Você pode então definir o fragment da href para essa string.

 var encodedState = base64(json(state)); var newLocation = oldLocationWithoutFragment + "#" + encodedState; document.location = newLocation; // adds new entry in browser history document.location.replace(newLocation); // replaces current entry in browser history 

A primeira maneira tratará o novo estado como um novo local (assim, o botão Voltar os levará para o local anterior). Este último não.

O SWFAddress funciona em projetos Flash & Javascript e permite que você crie URLs para bookmarkable (usando o método de hash mencionado acima), além de oferecer suporte a back-button.

http://www.asual.com/swfaddress/

O método window.location.hash é a maneira preferida de fazer as coisas. Para obter uma explicação sobre como fazer isso, Padrões Ajax – URLs exclusivos .

A YUI tem uma implementação desse padrão como um módulo, que inclui o trabalho específico do IE para obter o botão Voltar trabalhando junto com a reescrita do endereço usando o hash. YUI Browser History Manager .

Outras estruturas também têm implementações semelhantes. O ponto importante é que, se você quiser que o histórico funcione junto com a reescrita do endereço, os diferentes navegadores precisam de maneiras diferentes de lidar com ele. (Isso está detalhado no primeiro artigo do link.)

O IE precisa de um hack baseado em iframe, onde o Firefox produzirá um histórico duplo usando o mesmo método.

Se OP ou outros ainda estiverem procurando uma maneira de modificar o histórico do navegador para ativar o estado, usar pushState e replaceState, como sugerido por IESUS, é a maneira “certa” de fazê-lo agora. É a principal vantagem sobre location.hash parece ser que ele cria urls reais, não apenas hashes. Se o histórico do navegador usando hashes for salvo e revisitado com o javascript desabilitado, o aplicativo não funcionará, pois os hashes não são enviados para o servidor. No entanto, se pushState tiver sido usado, toda a rota será enviada ao servidor, que você poderá construir para responder adequadamente às rotas. Eu vi um exemplo em que os mesmos modelos de bigode eram usados ​​no servidor e no lado do cliente. Se o cliente tivesse o javascript habilitado, ele receberia respostas rápidas evitando a ida e volta ao servidor, mas o aplicativo funcionaria perfeitamente sem o javascript. Assim, o aplicativo pode degradar graciosamente na ausência de javascript.

Além disso, acredito que exista algum framework lá fora, com um nome como o history.js. Para navegadores que suportam HTML5, ele usa pushState, mas se o navegador não suportar isso, ele automaticamente voltará a usar hashes.

Verifique se o usuário está “na” página, quando você clica na barra de URL, o JavaScript diz que você está fora da página. Se você alterar a barra de url e pressionar ‘ENTER’ com o símbolo ‘#’ dentro dela, você irá para a página novamente, sem clicar na página manualmente com o cursor do mouse, então um comando keyboad event (document.onkeypress) do javascript irá Ser capaz de verificar se é entrar e ativa o javascript para redirecionamento. Você pode verificar se o usuário está na página com window.onfocus e verifique se ele está fora com window.onblur.

Sim, é possível.

😉