No ano anterior, a equipe do Polymer passou muito tempo ensinando os 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 do Polymer e pelos elementos Brick criados pela equipe da Mozilla.
À medida que os desenvolvedores se familiarizam com a criação de elementos e começam a pensar em criar aplicativos, várias perguntas surgem:
- Como você deve estruturar a interface do seu aplicativo?
- Como você faz a transição entre diferentes estados?
- Quais são algumas estratégias para melhorar a performance?
- E como você deve oferecer 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 fiz:
Estrutura
Dividir um aplicativo em partes modulares que podem ser combinadas e reutilizadas é um princípio central dos Web Components. Os elementos core-* e paper-* do Polymer facilitam o início com pequenas partes, como paper-toolbar e paper-icon-button.
E, com o poder da composição, combine-os com qualquer número de elementos para criar um esqueleto de aplicativo.
Depois de criar um esqueleto genérico, você pode aplicar seus próprios estilos CSS para transformar isso em uma experiência exclusiva da sua marca. A beleza de fazer isso com componentes é que você pode criar experiências muito diferentes usando as mesmas primitivas de criação de apps. Com um esqueleto em vigor, você pode pensar no conteúdo.
Um elemento especialmente adequado para lidar com muito conteúdo é o core-list.
O core-list pode ser conectado a uma origem de dados (basicamente uma matriz de objetos) e, para cada item na matriz, ele gera uma instância de modelo. No modelo, você pode aproveitar o poder do sistema de vinculação de dados do Polymer para conectar rapidamente o conteúdo.
Transições
Com as várias seções do app projetadas e implementadas, a próxima tarefa é descobrir como navegar entre elas.
Embora ainda seja um elemento experimental, core-animated-pages fornece um sistema de animação com plug-in 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 os URLs corretamente.
No mundo dos componentes da Web, o roteamento tem dois tipos: imperativo e declarativo. A combinação de core-animated-pages com qualquer uma das abordagens pode ser válida, dependendo das necessidades do projeto.
Um roteador imperativo (como o Director do Flatiron) 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 rota for correspondida e antes que a próxima seção seja ativada.
Por outro lado, um roteador declarativo (como app-router) pode combinar roteamento e core-animated-pages em um único elemento, facilitando o gerenciamento dos dois.
Se você quiser um controle mais refinado, use uma biblioteca como a more-routing, que pode ser combinada com core-animated-pages usando a vinculação de dados e possivelmente oferecer o melhor dos dois mundos.
Desempenho
À medida que seu aplicativo vai tomando forma, é preciso ficar de olho nos gargalos de desempenho, especialmente em tudo o 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 de desempenho vem do carregamento condicional dos polyfills de Web Components.
Não há motivo para incorrer em todos esses custos se a plataforma já tiver suporte total. Em cada versão do novo repositório webcomponents.js, os polyfills também foram divididos em arquivos independentes. Isso é ú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 há ganhos de rede significativos ao executar todas as importações de HTML usando 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
No entanto, criar um app 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 funcionar off-line, ele não será um app para dispositivos móveis. Atualmente, é possível usar o cache de aplicativos para desativar os recursos, mas, no futuro, o service worker vai melhorar muito a experiência de desenvolvimento off-line.
Jake Archibald publicou recentemente um livro de receitas de padrões de service worker, mas vou dar uma introdução rápida para você começar:
Instalar um service worker é muito fácil. Crie um arquivo worker.js e registre-o quando o aplicativo for inicializado.
É importante localizar o worker.js na raiz do aplicativo. Isso permite interceptar solicitações de qualquer caminho no app.
No gerenciador de instalação do worker, eu armazenei em cache uma grande quantidade de recursos (incluindo os dados que alimentam o app).
Isso permite que meu app ofereça pelo menos uma experiência alternativa ao usuário se ele estiver acessando o app off-line.
Avante!
Os Web Components são uma grande adição à plataforma da Web e ainda estão no início. À medida que elas forem lançadas em mais navegadores, caberá a nós, a comunidade de desenvolvedores, descobrir as práticas recomendadas para estruturar nossos aplicativos. As soluções acima são um ponto de partida, mas ainda há muito o que aprender. Vamos criar apps melhores!