HTML 5 – Parte 5 – Armazenando dados com Web Storage

Olá pessoal, tudo certin?

Continuo estudando HTML5 e estou gostando bastante do que estou aprendendo. Se você chegou agora e quiser ver o que já escrevi sobre o assunto, consulte:

• HTML5 – Parte 4 – Vídeo e Áudio
• HTML5 – Parte 3 – Formulários
• HTML5 – Parte 2 – Semântica para todos
• HTML5 – Parte 1 – história e elementos de estrutura

Hoje, pretendo falar um cadin sobre a nova API de armazenamento. Esta API não funciona, infelizmente, no IE9 beta (cada vez gosto menos do IE). Também não funcionou no Firefox.

Armazenamento hoje – importância e cookies

Armazenamento de dados associados com uma aplicação é uma atividade fundamental para praticamente todas as aplicações, sejam elas web ou desktop. Esta atividade pode incluir o armazenamento de uma chave para o tracking de páginas, nomes de usuários, preferências, entre outras coisas. Essa lista não teria fim.

Até aqui, armazenar dados associados a uma aplicação web exigia que gravação no lado do servidor e algumas chaves para link nos dois lados – o que significa que nossos dados são “separados” em dois lugares – ou ainda, há a possibilidade de usar cookies.

Entretanto, cookies são uma droga! O número de problemas que eles podem causar torna a simples idéia de trabalhar com cookies um sofrimento. Basta olhar a forma como eles trabalham para perceber como eles são desnecessariamente complicados.  Por exemplo, para setar um cooki em javascript seria algo parecido com isso:

Esse seria um cookie para a sessão. Agora, se desejássemos armazenar algo por um tempo mais longo, teríamos que prover um lifetime específico (e se desejássemos persistir, deveríamos revisar esse dado n dias no futuro). Observe:

Aqui, o formato da data também é importante. O que é mais uma razão para dores de cabeça. Agora, mais uma coisa ruim: Para deletar um cooki, precisamos setar o valor para vázio.

Na verdade, o cookie não é realmente deletado. O valor é apenas modificado e a expiração acontece junto com a sessão, logo, quando o browser é finalizado. Exclusão deveria significar exclusão! Não acha? Enfim, para mim, cookies são uma dor de cabeça.

Por sorte, a nova especificação é completamente diferente da abordagem de setar, recuperar…

As opções para armazenamento client-side da HTML5

Há duas opções para armazenamento client-side no html5:

1. Web Storage – suportada por todos os browsers;
2. Web SQL Databases – ainda não suportada por todos os browsers (mesmo os mais recentes).

Convenientemente, Web SQL Databases recebe este nome para nos fazer pensar, imediatamente, em como funciona: ou seka, usando uma sintaxe baseada em SQL para consultar um banco de dados local.

Web Storage, por outro lado, é muito mais simples. Basicamente, armazenamos valores associando-os a uma chave. Não é necessário nenhum conhecimento sobre SQL. Na verdade,  o suporte para esse padrão também é bem melhor do que o do Web SQL Databases, mas vou dar uma passada pelos dois formatos.

Como ponto de partida, devemos considerar que o formato Web Storage tipicamente tem o limite de 5Mb (embora o Safari, por exemplo, questione o usuário se a aplicação demandar mais de 5Mb).

Por outro lado, a especificação para Web SQL Databases não trata de limites de espaço.

Hoje, vou falar com mais detalhes sobre Web Storage

Sobre o Web Storage

Em poucas palavras, a API Web Storage parece cookies com esteróides !  

Uma vantagem chave para essa API é que ela separa dados de sessão de dados que precisam ser preservados por longos períodos de forma  mais explícita do que ocorre com cookies.

A Web Storage oferece dois tipos de armazenamento: sessionStorage e localStorage.

• Se um dado for criado em sessionStorage, ele ficará disponível apenas para a janela  que criou o dado até que esta seja fechada (por exemplo, quando a sessão for encerrada). Se você abrir outra janela, no mesmo domínio, ela não terá acesso aos dados daquela sessão.
• localStorage, por outro lado, é construída em torno do domínio e é compartilhada por todas as janelas abertas para aquele domínio. Ou seja, se você setar um dado no local storage esse ficará automaticamente disponível para quaiquer outras janelas no mesmo domínio. Além disso, ela permanecerá disponível até que seja explicitamente deletada pelo autor ou pelo o usuário. Perceba, o usuáriopode fechar sua janela, reiniciar seu computador, voltar dias depois e os dados vão continuar disponíveis. Dados persistentes sem a chatice de ter que setar a informação de “expiração” toda vez.

Apenas para comparar, se você “setar” uma cookie de sessão (isto é, uma cookie sem informações sobre expiração), o dado definido nessa cookie ficará disponível em todas as janelas que tiverem acesso para o domínio enquanto o browser não tiver sido encerrado.  O que é bem chatinho!

Uma forma fácil para salvar e recuperar dados

Como tanto sessionStorage e localStorage se originam na mesma especificação (Web Stgorage), ambas apresentam a mesma API.

Para salvar e recuperar dados é muito fácil. Observe:

getItem retornará nulo se a chave especificada não estiver associada a um dado.

Fácil, não?!

Mas, nem tudo são flores! getItem não retorna qualquer tipo de dados. Os browsers convertem o dado para string. Isso é uma coisa importante por que significa que se tentarmos armazenar um “object”, teremos um string sendo armazenado. Mais importante, isso significa que números sendo armazenados são convertidos também para strings, o que pode causar erros difíceis de depurar.

Uma forma ainda mais fácil para salvar e recuperar dados

Achou simples trabalhar com Web Storage? Então, pode ser ainda mais simples! Lembrando tipos dinâmicos, tanto sessionStorage quanto localStorage suportam expandos.

Repare:

Infelizmente esse método também não resolve o problema da “conversão indesejada para strings”.

Recuperando todos os dados armazenados

A API Web Storage provê ainda um método key que pega um índice provido como parâmetro e retorna a chave associada. Este método é útil para listar todos os dados armazenados em um objeto storage (local ou session). Observe:

Removendo dados

Há duas forma de remover dados do objeto storage (local ou session). São eles:

1. removeItem(key) – chamando esse método, removemos a entrada correspondente a key do objeto storage.
2. clear() – apaga todos os dados armazenados no storage.

Armazenando mais que strings

Podemos dar uma “curva” no fato dos objetos storage armazenarem todos os valores como strings usando JSON. Como JSON utiliza texto para representar um objeto JavaScript, podemos usar esse recurso para armazenar objetos e converter os dados armazenados outra vez para objetos. Repare que se trata de uma curva para contornar esse “bug”. Observe:

Não é que funciona?

Definindo HTML5

Como prometido, durante essa série, na medida em que vamos conhecendo mais detalhes do HTML5, vou tentar ir criando uma definição para a linguagem. Com o que temos aqui, podemos dizer que:

HTML5 é a sucessora oficial para o HTML 4.01, que está sendo desenvolvida paralelamente pelo W3C e pelo WHATWG, que dá ênfase maior para a semântica do que para a sintaxe. Incorporou mais significado aos documentos mediante novas TAGs de indicação ao conteúdo. Além disso, simplificou drasticamente a criação de formulários e players de áudio/vídeo reduzindo muito a necessidade da escrita de código JavaScript ou plugins. Define também duas novas API de persistência bem superiores ao mecanismo de cookies.

Por enquanto, é o que temos. Vamos avançar mais nos estudos para poder complementar essa definição!

Bem pessoal… por hoje, era isso!