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 Brick criados pela equipe da Mozilla.
À medida que os desenvolvedores se familiarizam com a criação de elementos próprios e começam a pensar na criação de aplicativos, surgem diversas perguntas:
- Como você deve estruturar a IU do seu aplicativo?
- Como fazer a transição entre diferentes estados?
- Quais são algumas estratégias para melhorar a performance?
- E como você pode oferecer uma experiência off-line?
Na Conferência de Desenvolvedores do Chrome, tentei responder a essas perguntas criando um pequeno aplicativo de contatos e analisando o processo de elaboração dele. Aqui está o que eu encontrei:
Estrutura
Dividir um aplicativo em partes modulares que podem ser combinadas e reutilizadas é um locatário central do Web Components. Com os elementos núcleo* e papel* do Polymer, é fácil começar com partes pequenas, como barra de ferramentas principal e botão de ícone de papel...
...e, com o poder da composição, eles podem ser combinados com qualquer número de elementos para criar um scaffold do aplicativo.
Depois de criar um scaffolding genérico, é possível aplicar seus próprios estilos CSS para transformá-lo em uma experiência única para sua marca. A beleza de fazer isso com componentes é que permite criar experiências muito diferentes, aproveitando os mesmos primitivos de criação de apps. Com um scaffolding instalado, é possível começar a pensar sobre o conteúdo.
Um elemento especialmente adequado para lidar com muito conteúdo é 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 vai carimbar uma instância de modelo. Dentro do modelo, você pode aproveitar o poder do sistema de vinculação de dados da Polymer para conectar seu conteúdo rapidamente.
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, o core-animated-pages fornece um sistema de animação conectável que pode ser usado para fazer a transição entre diferentes estados no aplicativo.
Mas a animação é apenas metade do quebra-cabeça, um aplicativo precisa combinar essas animações com um roteador para gerenciar corretamente seus URLs.
No mundo do Web Components, o roteamento tem dois tipos: imperativo e declarativo. Combinar core-animated-pages com qualquer uma das abordagens pode ser válido dependendo das necessidades do 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 realizar tarefas depois da correspondência de um trajeto 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 o core-animated-pages em um único elemento, o que facilita o gerenciamento dos dois.
Se você quiser um controle mais refinado, use uma biblioteca como o mais roteamento, que pode ser combinado com core-animated-pages usando vinculação de dados e oferece o melhor dos dois mundos.
Performance
À medida que seu aplicativo vai tomando forma, você precisa ficar de olho nos gargalos de desempenho, especialmente qualquer coisa associada à rede, já que essa geralmente é a parte mais lenta de um aplicativo da Web para dispositivos móveis.
O carregamento condicional de polyfills da Web Components garante um aumento no desempenho fácil.
Não há motivo para gastar todo esse custo se a plataforma já tem 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 significativos de rede com a execução de todas as importações de 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 é um app para dispositivos móveis. Atualmente, é possível usar o cache de aplicativos muito malicioso para manter os recursos off-line, mas, no futuro, o service worker logo deve tornar a experiência de desenvolvimento off-line muito melhor.
Jake Archibald publicou recentemente um livro de receitas incrível de padrões de service workers (em inglês), mas vou dar o início rápido para você 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 uma carga de recursos (incluindo os dados que alimentam o aplicativo).
Isso permite que meu app forneça pelo menos uma experiência de substituição para o usuário se ele estiver acessando o app off-line.
Em frente!
Os componentes da web são uma grande adição à plataforma da web e ainda estão em sua infância. À medida que chegarem a mais navegadores, cabe a nós, a comunidade de desenvolvedores, determinar as práticas recomendadas para estruturar nossos aplicativos. As soluções acima são um ponto de partida, mas ainda há muito mais a aprender. Siga para a criação de apps melhores!