O HTML5 localStorage é assíncrono?
A setItem(key,value)função é assíncrona?
localStorage.setItem("key",someText);
— jas7
Eu não deveria pensar assim. Downvoter: qual é a sua lógica?
— Waleed Khan
Relacionados: stackoverflow.com/questions/17349584/...
— megawac
Não, todas as localStoragechamadas são síncronas.
— Ryan Nigro
Minha fonte original eram os documentos de armazenamento local da Mozilla, mas parece que eles foram revisados ​​desde então (e a especificação W3 não parece exigir sincronização / assíncrona em qualquer lugar). Nesse ponto, eu diria que as chamadas de armazenamento local são síncronas por convenção, mas não por especificação. A menos que você conheça um navegador que o implementou de forma assíncrona?
meu problema é que eu defino um token de autenticação no armazenamento local e redireciono o usuário para outra exibição. Às vezes, na nova visualização, o acesso ao armazenamento local descobre que o token ainda não foi salvo, portanto, tenho que usar um tempo limite, mas ainda não é 100% confiável.
@TheMuffinMan: Seu problema provavelmente está relacionado ao nbfou a exppartir do token de autenticação.
Mesmo para mim, coisas estranhas
— patotoma
Estou enfrentando o mesmo problema ... é um comportamento estranho.
— Daniel T. Sobrosa
Na realidade. o armazenamento na web não faz mais parte do padrão principal do HTML5, foi dividido.
A especificação (rascunho) relevante pode ser encontrada aqui e a única coisa que você notará é que ela não menciona síncrona ou assíncrona em nenhum lugar.
No entanto, a análise do texto sugere que ele deve ser síncrono (em negrito):
O método setItem (chave, valor) deve primeiro verificar se um par de chave / valor com a chave fornecida já existe na lista associada ao objeto.
Caso contrário, um novo par de chave / valor deve ser adicionado à lista, com a chave fornecida e seu valor definido como valor.
Se a chave fornecida existir na lista e seu valor não for igual ao valor, ele deverá ter seu valor atualizado para valor. Se o seu valor anterior for igual ao valor, o método não deve fazer nada.
Em padrões, palavras como must, shalle maylevar muito significados específicos. O fato de estar falando sobre o que o método deve fazer significa que o próprio método deve fazê-lo, não o adiará mais tarde.
Isso também adia o bom senso. Se os setItemfossem assíncronos, seria possível definir um item para um valor específico e recuperá-lo imediatamente, obtendo seu valor anterior.
Não é uma nota na parte inferior da seção interface de armazenamento que aponta para a possibilidade de comportamento assíncrono:
Esta especificação não exige que os métodos acima esperem até que os dados sejam gravados fisicamente no disco. É necessária apenas consistência no que os diferentes scripts que acessam a mesma lista subjacente de pares chave / valor são necessários.
No entanto, isso é apenas em termos do que é gravado no armazenamento a longo prazo. A última frase exige que os scripts que acessam o mesmo objeto de armazenamento sejam necessários para ver as coisas de forma síncrona.
De fato, as coisas não são necessariamente liberadas para o disco de uma só vez; portanto, se você fechar e abrir novamente sua página, talvez não tenha os elementos mais recentes armazenados. Eu testei isso em um aplicativo híbrido no Android e, em alguns casos, torna o uso do localStorage inapropriado.
Eu preciso armazenar algum objeto que eu tenho que em página diferente, o mais apropriado é o uso LocalStorage. Quando guardo 10 itens, sinto falta de 3 deles. Eu realmente acredito que é assíncrono, mas como verificar se foi feito. onde eu tenho que adicionar retorno de chamada?
Tropeçamos sobre isso e achava que isso era interessante para adicionar ao must, shall, maycomentário acima RFC2119 ietf.org/rfc/rfc2119.txt
Também estou vendo um comportamento assíncrono. Quando salvo um objeto vazio em um item, percebo que, ao recuperar os dados do item, imediatamente retorna os dados antigos antes de salvar. Se eu fosse para adivinhar, é provavelmente apenas o atraso de escrever para o disco
@sookie O sistema operacional deve ocultar quaisquer problemas de hardware como esse. Os aplicativos são lidos no cache do buffer do sistema operacional, não diretamente no disco.
Esta pergunta já foi respondida. Para quem chega a isso no futuro, o javascript é síncrono por natureza. As coisas são apenas assíncronas, elas são especificadas para isso. Por esse motivo, você pode assumir que todas as coisas são síncronas, a menos que sejam especificadas para serem assíncronas. Isso é com javascript, não estruturas escritas em Javascript. Às vezes eles quebram essa prática. Como os NodeJs.