A Sessão

Lateral 5.5

Porcentagem Traduzida

Neste capítulo, você irá:

  • Aprenda sobre a Sessão no Meteor.
  • Aprenda sobre a função autorun.
  • Aprenda sobre Hot Code Reload
  • Meteor é um framework reativo. O que significa é que quando os dados são alterados, coisas em sua aplicação mudam sem você ter que explicitamente fazer alguma coisa.

    Nós já vimos isso em ação e como nossos templates mudam quando os dados e as rotas mudam.

    Vamos mergulhar fundo e saber como isso funciona nos próximos capítulos, mas por agora, gostaríamos de introduzir algumas propriedades básicas da reatividade que são extremamente úteis para maioria das aplicações.

    A Meteor “Session”

    Agora no Microscope, o estado atual da aplicação do usuário está completamente contido na URL que ele está procurando (e o banco de dados).

    Mas em vários casos, você vai precisar armazenar algum estado efêmero que só é relevante a versão atual do usuário da aplicação (por exemplo, se um elemento está exposto ou escondido). A Session é uma forma conveniente de se fazer isso.

    A Session é um dado reativo global armazenado. Ele é global no sentido de um objeto singleton global: há uma sessão, e ela é acessível em todo lugar. Variáveis globais geralmente são vistas como coisas ruins, mas neste caso a sessão é usada como um veículo central de comunicação para diferentes partes da aplicação.

    Mudando a Session

    Esta “sessão” está disponível como Session. Para configurar um valor de sessão, você pode chamar:

     Session.set('pageTitle', 'A different title');
    
    Browser console

    Você pode ler o dado de volta com Session.get('mySessionProperty');. Isso é uma fonte reativa de dados, que significa que se você colocá-la em um helper, você verá a saída do helper mudando reativamente quando a variável Session for alterada.

    Para testar isso, adiocione o seguinte código no modelo do layout.

    <header class="navbar">
      <div class="navbar-inner">
        <a class="brand" href="{{pathFor 'postsList'}}">{{pageTitle}}</a>
      </div>
    </header>
    
    client/views/application/layout.html
    Template.layout.helpers({
      pageTitle: function() { return Session.get('pageTitle'); }
    });
    
    client/views/application/layout.js

    A atualização automatica do Meteor (conhecida como “hot code reload” HCR) conserva as varáveis Session, então podemos agora ver “A different title” na barra de navegação. Se não, apenas digite o comando Session.set() novamente.

    Além disso se nós mudarmos o valor mais uma vez (novamente no console do browser), nós vamos ver outro título sendo mostrado:

     Session.set('pageTitle', 'A brand new title');
    
    Browser console

    Session está disponível globalmente, então estas mudanças podem ser feitas em qualquer lugar da aplicação. Isso nos dá muio poder, mas pode também ser uma armadilha se usado exageradamente.

    Mudanças Idênticas

    Se você modificar uma variável Session com Session.set() mas configurá-la com um valor idêntico, o Meteor é inteligente o suficiente para desviar a cadeia reativa, e evitar a chamada do método.

    Introduzindo o Autorun

    Vimos um exmplo de fonte de dados reativa, e também vimos isso em ação dentro de um template helper (modelo auxiliar). Mas enquanto alguns contextos no Meteor (como os template helpers) são inerentemente reativos, a maioria do nosso código Meteor continua sendo o bom e velho JavaScript não-reativo.

    Vamos supor que temos o seguinte trecho de código em algum lugar de nosso aplicativo:

    helloWorld = function() {
      alert(Session.get('message'));
    }
    

    Mesmo que estejamos chamando uma variável Session, o contexto em que a chamada é feita não é reativo, significando que nós não vamos ter um novo alert toda as vezes que mudarmos a variável.

    Ai é onde o Autorun entra. Como o nome implica, o código dentro de um bloco autorun vai rodar automaticamente e continuar rodando toda vez que a fonte de dados reativa usada mudar.

    Tente digitar isso dentro do console do navegador:

     Deps.autorun( function() { console.log('Value is: ' + Session.get('pageTitle')); } );
    Value is: A brand new title
    
    Console do navegador

    Como se poderia esperar, o bloco de código fornecido dentro de autorun roda uma vez, retornando esse dado para o console. Agora, vamos tentar mudar o título:

     Session.set('pageTitle', 'Yet another value');
    Value is: Yet another value
    
    Console do navegador

    Mágica! Como o valor da sessão mudou, o autorun sabia que tinha que rodar este conteúdo todo novamente, re-imprimindo o novo valor no console.

    Agora voltando ao exemplo anterior, se nós queremos disparar um novo alerta toda as vezes que nossa variável Session for alterada, tudo que temos que fazer é envolver nosso código em um bloco autorun:

    Deps.autorun(function() {
      alert(Session.get('message'));
    });
    

    Como acabamos de ver, autoruns pode ser muito útil para rastrear fontes de dados e reagir imperativamente com elas.

    Hot Code Reload

    Durante nosso desenvolvimento do Microscope, temos tirado proveito de uma das propriedades do Meteor que salvam tempo: Hot Code Reload (HCR). Sempre que salvamos um de nossos arquivos de códigos, o Meteor detecta a mudança e reinicia o servidor, informando a cada cliente do recarregamento da página.

    Isso é similar a uma atualização automática da página, mas com uma importante diferença.

    Para saber qual é essa diferença, comece reconfigurando a variável Session que temos usado:

     Session.set('pageTitle', 'A brand new title');
     Session.get('pageTitle');
    'A brand new title'
    
    Browser console

    Se nós recarregarmos nossa janela do navegador manualmente, nossa variável Session naturalmente vai ser perdida (uma vez que seria criada uma nova sessão). Do outro lado, se nós dispararmos um hor code reload (por exemplo, salvando um de nossos arquivos de código) a página vai ser recarregada, mas a variável session vai continuar configurada. Tente agora!

     Session.get('pageTitle');
    'A brand new title'
    
    Browser console

    Então se estivermos usando variáveis de sessão para rastrear exatamente o que o usuário está fazendo, o HCR deve ser transparente para o usuário, pois isso vai preservar o valor de todas as variáveis de sessão. Isso nos permite fazer o deploy de novas versões em produção de nossas aplicações Meteor com a confiança de que nossos usuários vão ser minimamente interrompidos.

    Considere isso por um instante. Se nós podemos manter todo o nosso estado na URL e na sessão, nós podemos transparentemente mudar o código fonte rodando por baixo de cada aplicação do cliente com uma interrupção mínima.

    Vamos checar o que acontece quando nós atualizamos a página manualmente:

     Session.get('pageTitle');
    null
    
    Browser console

    Quando nós recarregamos a página, nós perdemos a sessão. Com o HCR, o Meteor salva a sessão em local storage no seu navegador e a carrega novamente depois do recarregamento. Entretanto, o comportamente alternativo no recarregamento explícito faz sentido: se um usuário recarrega a página, é como se ele tivesse ido para a mesma URL novamente, e ele deseja resetar ao ponto inicial que qualquer usuário vai ver quando visita a URL.

    As importantes lições em tudo que foi visto são:

    1. Sempre armazene esados de usuário na Session ou na URL, assim os usuários serão minimamente interrompidos quando um HCR acontecer.
    2. Armazene qualquer estado que você queira que seja compartilhável entre usuários dentro da própria URL.