No ano anterior, a equipe da Polymer passou muito tempo ensinando desenvolvedores a criar os próprios elementos. Isso levou a um ecossistema em rápido crescimento, impulsionado em grande parte pelos elementos Core e Paper da Polymer e pelos elementos de tijolos criados pela equipe do Mozilla.
À medida que os desenvolvedores se familiarizam mais com a criação de elementos próprios e começam a pensar sobre a criação de aplicativos, várias questões surgem:
- Como você precisa estruturar a interface do seu aplicativo?
- Como você faz a transição por estados diferentes?
- Quais são algumas estratégias para melhorar a performance?
- E como você deve fornecer uma experiência off-line?
Para o Chrome Dev Summit, tentei responder a essas perguntas criando um pequeno aplicativo de contatos e analisando o processo que passei para criá-lo. Aqui está o que eu pensei:
Estrutura
Dividir um aplicativo em partes modulares que podem ser combinadas e reutilizadas é uma parte central do Web Components. Com os elementos core-* e paper-* do Polymer, é fácil começar com partes pequenas, como a barra de ferramentas principal e o botão-ícone-de-papel...
...e, com o poder da composição, combine-as com qualquer número de elementos para criar um scaffolding de aplicativo.
Assim que tiver uma estrutura genérica, você poderá aplicar seus próprios estilos de CSS para transformá-la em uma experiência única para sua marca. A beleza de fazer isso com componentes é que isso permite criar experiências muito diferentes, aproveitando as mesmas primitivas de criação de apps. Com um scaffolding, você pode começar a pensar no conteúdo.
Um elemento especialmente adequado para lidar com muitos conteúdos é o core-list.
O core-list pode ser conectado a uma fonte de dados (basicamente uma matriz de objetos) e, para cada item na matriz, ele carimba uma instância de modelo. No modelo, você pode aproveitar a eficiência do sistema de vinculação de dados da Polymer para conectar seu conteúdo com rapidez.
Transições
Depois de projetar e implementar as várias seções do app, a próxima tarefa é descobrir como realmente navegar entre elas.
Embora ainda seja um elemento experimental, core-animated-pages fornece um sistema de animação conectável que pode ser usado para fazer a transição entre diferentes estados no seu app.
Mas a animação é apenas metade do quebra-cabeça: um aplicativo precisa combinar essas animações com um roteador para gerenciar adequadamente seus URLs.
No mundo do roteamento do Web Components, ele tem duas variações: imperativo e declarativo. Combinar core-animated-pages com qualquer uma das abordagens pode ser válido dependendo das necessidades do seu projeto.
Um roteador imperativo (como o Flatiron's Director) pode detectar uma rota correspondente e instruir o core-animated-pages a atualizar o item selecionado.
Isso pode ser útil se você precisar fazer algum trabalho depois que uma correspondência de rota for feita e antes da transição da próxima seção.
Por outro lado, um roteador declarativo (como o app-router) pode combinar o roteamento e core-animated-pages em um único elemento, tornando o gerenciamento dos dois mais simplificado.
Se quiser um controle mais refinado, use uma biblioteca como a mais roteamento, que pode ser combinada com core-animated-pages usando vinculação de dados e possivelmente oferece o melhor dos dois mundos.
Desempenho
À medida que seu aplicativo está tomando forma, é preciso ficar atento aos gargalos de desempenho, especialmente a tudo que estiver associado à rede, já que essa geralmente é a parte mais lenta de um aplicativo da Web para dispositivos móveis.
Uma vitória fácil no desempenho vem do carregamento condicional dos polyfills do Web Components.
Não há motivo para ter todo esse custo se a plataforma já tem suporte total. Em cada lançamento do novo repositório webcomponents.js, os polyfills também foram divididos em arquivos independentes. Isso será útil se você quiser carregar condicionalmente um subconjunto dos polyfills.
<script>
if ('import' in document.createElement('link')) {
// HTML Imports are supported
} else {
document.write(
'<script src=“bower_components/webcomponentsjs/HTMLImports.min.js"><\/script>'
);
}
</script>
Também é possível obter ganhos de rede significativos ao executar todas as importações HTML por meio de uma ferramenta como o Vulcanize.
O Vulcanize concatena as importações em um único pacote, reduzindo significativamente o número de solicitações HTTP feitas pelo app.
Off-line
Mas apenas criar um aplicativo com bom desempenho não resolve o dilema de um usuário com pouca ou nenhuma conectividade. Em outras palavras, se o app não funciona off-line, ele não é realmente um app para dispositivos móveis. Atualmente é possível usar o tão maligno cache de aplicativos para off-line seus recursos, mas, considerando o futuro, o service worker logo vai tornar a experiência de desenvolvimento off-line muito melhor.
Jake Archibald publicou recentemente um incrível manual de padrões para service workers, mas vou dar a você o início rápido para começar:
É muito fácil instalar um service worker. Crie um arquivo worker.js e registre-o quando seu aplicativo for inicializado.
É importante localizar o worker.js na raiz do aplicativo. Isso permite que ele intercepte solicitações de qualquer caminho no app.
No gerenciador de instalação do worker, armazeno em cache vários recursos (incluindo os dados que alimentam o aplicativo).
Isso permite que meu app ofereça pelo menos uma experiência substituta para o usuário se ele estiver acessando off-line.
Siga em frente!
Os componentes da Web são uma grande adição à plataforma da web e ainda estão na infância. À medida que eles chegarem em mais navegadores, cabe a nós, a comunidade de desenvolvedores, descobrir as práticas recomendadas para estruturar nossos aplicativos. As soluções acima nos dão um ponto de partida, mas ainda há muito mais a aprender. Avance para a criação de apps melhores.