Acabamos de concluir um projeto que apresentava vários padrões nos quais estou muito
interessado:
- Visualizações geradas pelo cliente
- Ember.js
- Rails apenas como API, sem visualizações
O objetivo do projeto era lançar uma ferramenta que permitisse aos que
programam aulas na faculdade saber quando outras aulas estão sendo programadas. Os
programadores podem então usar esses dados para programar aulas que conflitam
com o menor número possível de outras classes.
Como o aplicativo acabou sendo 3 camadas bastante distintas, irei
dividir essas postagens retrospectivas de forma semelhante. Vou começar com o código em que mais
trabalhei, a biblioteca de visualização.
Começando com D3
Depois que conseguimos que o cliente concordasse que o IE8 não seria compatível, usar o
D3 como nossa ferramenta de visualização fez todo o sentido. É
poderoso, rápido e amplamente utilizado. Se tivéssemos que suportar o IE8, teríamos
que procurar em outro lugar, já que o D3 gera gráficos SVG, que
não são suportados pelo IE8.
Recebi a tarefa de prototipar visualizações em D3 e aprender sua
sintaxe, como nenhum de nós tinha usado antes. Eu rapidamente resolvida usando uma
visualização calor mapa, como este
um .
A sintaxe D3 pode ser desafiadora quando você a aborda pela primeira vez, mas achei mais
fácil focar em aprender apenas sobre essa visualização: como ela é
gerada, quais parâmetros são necessários, como posso manipulá-la. Existem
muitos recursos do D3, 90% dos quais eu não precisei para este projeto.
Portanto, ao focar nos recursos de que precisava, tornei a curva de aprendizado
mais gerenciável.
Logo eu tinha uma visualização de demonstração que foi aceita pela equipe. Estava longe de ser perfeito, mas nos mostrou o caminho.
Embrulhar
À medida que o código do heat map se desenvolvia, comecei a pensar em como o
aplicativo da web , que estava sendo escrito em Ember, interagiria com ele.
A maioria dos projetos que encontramos simplesmente tem o Ember interagindo diretamente com o D3. Mas decidi evitar isso por alguns motivos:
- A visualização provavelmente seria reutilizada em outros aplicativos
- Diminuir o acoplamento nos permitiria trocar as bibliotecas de visualização caso D3 não seja o que queremos.
Portanto, o objetivo passou a ser envolver a criação da visualização e atualizar o código com
uma API. Ele aceitaria uma estrutura de dados e algumas opções de configuração
e ocultaria totalmente o D3 do Ember.
Isso me deu um benefício adicional, testabilidade. Eu não queria testar o D3,
porque tudo que eu estaria fazendo é afirmar que o D3 funciona como anunciado,
algo que seu próprio conjunto de testes deveria fazer. Mas testar um wrapper fazia
sentido, e esses testes serviriam como documentação de como a
API de visualização funcionava.
Esse tipo de abordagem modular de JavaScript é nova para mim, por isso exigiu algumas
pesquisas. Aprender JavaScript Design Patterns foi uma grande ajuda (e gratuita) para mim, especialmente a seção sobre o Padrão de Módulo Revelador , que é mais ou menos o que eu segui.
O teste foi feito no Jasmine que
foi ok. Eu não me importo com a forma como ele lida com testes duplos (ou ‘espiões’, como os
chama). Achei a sintaxe para zombarias e expectativas
particularmente estranhas. Mas é rápido e se integrou bem com o código em
que estava trabalhando. Eu quero tentar outras estruturas de teste para ver se a
sintaxe é mais fácil de resolver. Mas talvez esse problema de sintaxe seja intrínseco
ao JavaScript.
O Produto Final
E, no final disso, acabei com uma biblioteca de visualização modular
totalmente separada do Ember e pronta para ser inserida em qualquer projeto
que possa precisar. * Tudo o que o projeto precisa saber são três
métodos simples :
viz = Visualization.HeatMap.new(dom_node, [data objects], {configuration});
viz.update([data objects]);
viz.destroy();A visualização final percorreu um longo caminho desde a minha demonstração inicial:
E a partir disso você pode ver facilmente o que você esperaria ver,
as aulas da faculdade agrupadas em torno do horário nobre de terça / quinta-feira e
ninguém tendo aulas na sexta-feira.
E é isso. Bem, quase. Acontece que integrar tudo isso
com o Ember é mais complicado do que você pensa. Mas esse é outro post.
* Quero colocar mais código nesta retrospectiva e um link para o
projeto final no GitHub, mas no momento não é público. Assim que puder torná-
lo público, compartilharei o código aqui.