Backbone: History.navigate deve permitir a configuração do objeto de estado

Receio discordar - mas, por favor, tente me persuadir do contrário.

O objetivo da API de histórico é fornecer URLs marcáveis ​​e compartilháveis, para os quais você possa navegar de volta. Se você anexar um objeto de histórico com a API, a página para a qual você navega de volta _não_ é a mesma que a página que você veria se colasse o URL idêntico. Isso parece quebrado ... e no mínimo redundante com sua capacidade de armazenar estado arbitrário em JS durante o curso de uma sessão do navegador.

Tem o cheiro de uma API onde os implementadores do navegador pensaram, "puxa, não seria legal se você pudesse ...", e não consideraram as consequências reais.

Acho que você está fazendo suposições sobre o comportamento desejável do aplicativo e também a granularidade dos eventos de histórico que são mais restritivos do que o que a API do navegador fornece. Especificamente, não há razão para que seja responsabilidade da estrutura e não do aplicativo ditar o comportamento quando invocado com um URI. Parece perfeitamente e obviamente legítimo que haja estado (dado pelo caminho de navegação) ortogonal ao recurso (e estado codificado) identificado pelo URI, e que a apresentação seja condicionada a ambos. É claro que essa escolha deve ser feita pelo aplicativo individual.

Além desse argumento abstrato, diga-me como você implementaria, por exemplo, um formulário de entrada de marcador que oferece para salvar / descartar alterações quando navegado para fora (incluindo com o botão Voltar) usando a API de histórico?

Esta é uma mudança de uma ou duas linhas. Se você não quiser adicionar um parâmetro a History.navigate , também pode ser feito o uso do estado fornecido por meio de, por exemplo, um atributo ou função currentState .

diga-me como você implementaria, por exemplo, um formulário de entrada que pode ser marcado
que se oferece para salvar / descartar alterações quando navegado para fora de (incluindo
com o botão Voltar) usando a API de histórico?

Eu simplesmente armazenaria as alterações do formulário em um lugar diferente e mais seguro: Na sessão, no servidor, no armazenamento local ...

Eu estava curioso para saber o que as pessoas pensavam dessa posição, então perguntei:

https://twitter.com/jashkenas/status/142736117895151616

E aqui estão algumas das respostas:

https://twitter.com/juandopazo/status/142737949178601472

https://twitter.com/yaypie/status/142737982879842304

https://twitter.com/fortes/status/142742305877659648

https://twitter.com/dyakovlev/status/142743995020349441

https://twitter.com/bassistance/status/142882410982420481

A API de histórico lida especificamente com o estado do aplicativo vinculado ao caminho de navegação, distinto do URI. Ou seja, "Como chegamos aqui?" Talvez devesse ser chamada de API Hysterisis. Podemos compartilhar o mesmo URI e estar na mesma 'página', mas não na mesma visualização / página / estado de retorno quando pressiono o botão Voltar do mouse ou deslizo de volta no seu celular. E essa ação de retorno pode alterar o estado / histórico do aplicativo sem alterar o URI. Nem todas as transições de navegação são transições de URI. Portanto, quando compartilhamos um URI, isso pode levar à apresentação do mesmo recurso ou 'página', mas não do mesmo estado de navegação.

Embora aprecie a experiência do seu rebanho, acho que só mostra que a maioria dos desenvolvedores ainda não descobriu como usar a API conforme pretendido pelos criadores. Esse não é um bom motivo para a estrutura pavimentá-lo.

Além disso, você não abordou a questão, que não era como persistir os valores do formulário, mas sim como usar a API push / popState para solicitar que o usuário salve as alterações, se houver, quando ele clicar no botão Voltar para navegar fora do formulário com o URI que pode ser marcado. Por favor, considere abordar isso.

Sou muito novo no Backbone e no WebDev em geral, mas concordo com o tribalvibes.

Quero criar um aplicativo da web com base na API Graph do Facebook e usar a função de navegação do Backbone para permitir que o usuário volte para diferentes itens para visualizar, semelhante ao que o Facebook faz agora. No entanto, sem o stateobject em pushState, o usuário precisa recarregar o item da API, o que obviamente é caro.

Provavelmente é porque eu não sei qual é o padrão comum para esse problema, mas acho que ter um objeto de estado para isso seria muito útil.

De acordo com a documentação do MDN, o objeto de estado é salvo no disco. Não entendo como isso é diferente de salvar no armazenamento local. Acho que isso deve ser corrigido. Usar o armazenamento local ou outro método de salvar o estado parece estranho quando você tem o objeto de estado disponível na API de histórico.

Certo, mas contra: o uso do objeto de estado deve ser estranho quando você tem armazenamento local, cookies ou qualquer outro método de salvar o estado que _não_ está simplesmente vinculado ao URL atual.

Por que não seria melhor utilizar a ferramenta fornecida? O objeto de estado fornece um método direto de salvar e acessar estados anteriores. Em vez de vasculhar o armazenamento local cada vez que um usuário chega a uma página, ter history.state disponível permitiria a capacidade de lembrar não apenas o estado genérico da visualização por meio da rota de url, mas também o estado específico dessa visualização que um usuário pode querer voltar para.

Na minha opinião, aplicativos simples que usam rotas devem usá-los de forma simples. Copie e cole o url para ter uma experiência completa. Aplicativos complexos devem usar rotas apenas como pontos de entrada simples para áreas gerais do aplicativo, ou registros particulares, e então usar apis de armazenamento que melhor representem o tipo de persistência, seja usuário (servidor), sessão ou local.

Usar o objeto de estado de histórico anula o que é ótimo sobre a maneira simples como os aplicativos de página única podem usar urls como marcadores potencialmente permanentes.

O backbone sempre foi muito flexível e menos opinativo do que outros frameworks. Não entendo por que isso é diferente com o window.history.pushState nativo. Eu entendo que algumas pessoas não gostem. No entanto, a decisão de usá-lo ou não deve ser deixada para o usuário final.

Então, por favor, repense.

@rafayepes Concordo totalmente com seu argumento. Eu adoro o Backbone e sua simplicidade, mas essa mudança de API introduz um monte de problemas e soluções alternativas no código, quando o aplicativo deve armazenar relacionamento 1 para 1 entre url e estado. A maneira nativa de interagir com a API de histórico seria muito mais fácil.