Desenvolvendo Web Components by Novatec Editora

Jarrod Overson e Jason Strimpel

Novatec

Authorized Portuguese translation of the English edition of titled Developing Web Components, ISBN 9781491949023 © 2015 Jason Strimpel and Jarrod Overson. This translation is published and sold by permission of O’Reilly Media, Inc., the owner of all rights to publish and sell the same. Tradução em português autorizada da edição em inglês da obra Developing Web Components, ISBN 9781491949023 © 2015 Jason Strimpel and Jarrod Overson. Esta tradução é publicada e vendida com a permissão da O’Reilly Media, Inc., detentora de todos os direitos para publicação e venda desta obra. © Novatec Editora Ltda. 2015. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates Tradução: Daniel Vieira Revisão gramatical: Viviane Oshima Editoração eletrônica: Carolina Kuwabata Assistente editorial: Priscila A. Yoshimatsu ISBN: 978-85-7522-427-4 IG20150415 Histórico de impressões: Abril/2015

Primeira edição

Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Email: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

capítulo 1

Introdução

Jarrod Overson e Jason Strimpel Que bom que você está aqui! Seja bem-vindo! Espero que tenha entrado num passeio divertido. Se você é do tipo que pula os prefácios dos livros, precisamos esclarecer algo rapidamente: este livro foi preparado de forma a acompanhá-lo na criação básica de widgets a partir de uma base em jQuery e depois traduzir esse conhecimento, primeiro para o mundo dos Web Components, e depois para o dos Web Components “polimerizados” (Web Components criados por meio do framework Polymer). Web Components estão na vanguarda absoluta, mas possuem pouco suporte na maioria dos browsers mais modernos; assim, temos um longo caminho a percorrer antes que as pessoas comecem a trabalhar com as melhores práticas mais aceitas. O grupo Polymer (https://www.polymer-project.org/) está liderando essa jornada, com o Mozilla (http://x-tags.org/) seguindo seu próprio caminho e os indivíduos na comunidade dando suas próprias opiniões, enquanto os Web Components começam a ser adotados em aplicações no mundo real. Nesse ambiente, achamos que a melhor ferramenta que poderíamos colocar nas mãos dos desenvolvedores interessados em Web Components fosse o conhecimento de como desenvolver facetas da interface do usuário (UI – User Interface) de maneira reutilizável, que também possa ser traduzida diretamente em Web Components se (e quando) você decidir utilizá-los. Neste livro, trataremos dos aspectos da UI para um widget comum em JavaScript, a caixa de diálogo. Iremos da criação básica até um componente web simples, e depois veremos o uso do Polymer para abstraí-lo, montá-lo e implantá-lo como um elemento HTML personalizado e reutilizável. Após a leitura deste livro, desejamos que você retenha principalmente este conhecimento: a introdução de Web Components, embora mude bastante, não exclui a necessidade de conhecer e entender como escrever em JavaScript moderno, e também não invalida a grande quantidade de bibliotecas e práticas que utilizamos e apreciamos 22

Capítulo 1 ■ Introdução

como parte do desenvolvimento web para o front-end. Dito isso, os Web Components certamente são um modo novo e interessante de tratar da lógica encapsulada e das interfaces do usuário, e o panorama está repleto de inovação e oportunidades.

Escolha sua própria aventura Este livro está dividido em quatro partes, permitindo que você comece a ler sobre o assunto que particularmente mais lhe interesse. Já está familiarizado com os conceitos da parte I, Conceitos básicos de UI? Então pule para a parte II, Criando nossa UI. Não está interessado em aprender sobre os detalhes do deploy de componentes da UI e como construir um componente de diálogo? Então mergulhe diretamente na parte III, Criando Web Components para HTML5, e aprenda tudo sobre essa nova tecnologia. Já sabe a respeito de Web Components e está ansioso aprender a utilizá-los nas aplicações em produção? Então, a parte IV, Teste, build e deploy de componentes com Polymer, é para você. O ponto onde você começa e termina fica totalmente a seu critério, e desejamos que tenha sucesso na sua aventura!

O que são Web Components? “Web Components” não são qualquer coisa; este é o termo usado para uma coleção de tecnologias que permitem que os desenvolvedores descrevam, de modo eficiente, as implementações dos elementos HTML que já existem. Mas o que significa isso? Bem, se você recebesse a tarefa de implementar uma tag <p> por meio de alguma outra combinação de HTML, JavaScript e CSS, como você faria? Você poderia razoavelmente considerar que a tag <p> descreve apenas um conjunto de estilos e talvez escrevesse um <div> com algum estilo em linha, ou talvez uma classe p que agrupe estilos de parágrafo. Mas como você implementaria, digamos, uma tag <select> e sua lista constituinte de tags <option>? Isso começa a ficar mais complicado. Pode ser feito, é claro, mas vai começar a ser uma mistura arriscada de estilos JavaScript e HTML. Imagine, então, como a implementação seria frágil. Os estilos podem colidir com a página que os utiliza, assim como as classes, IDs, JavaScript global etc. Novamente, isso pode ser feito, e já o fizemos, mas está longe de ser o ideal.

Desenvolvendo Web Components

Mais à frente no mesmo caminho, como você implementaria a tag <video>? Isso começa a ficar cada vez mais arriscado, e são esses os tipos de problemas que as tecnologias de Web Components tentam resolver. Elas não fazem tudo, mas dão aos desenvolvedores um modo padrão de encapsular, proteger e empacotar esses conceitos. Mesmo que você ache que os Web Components não são tão maravilhosos (o que eles são, considerando que podem tornar o desenvolvimento web muito mais satisfatório e interessante), as tecnologias constituintes são todas úteis, independentemente, e sem dúvida terão lugar em frameworks como Angular e Ember, de modo que vale a pena estar informado a respeito delas, bem como compreendê-las. O que é curioso a respeito dos Web Components é que a maior parte deles é irritantemente óbvia. Dois anos depois que você aceitar os Web Components sem reservas, olhará para a primeira década do século como aquela era primitiva, repleta de frameworks neanderlíticos e “melhores práticas”, que envolviam colocar templates de string inteiros em tags <script>. Ao relatar essa era de desenvolvimento aos seus netos, eles olharão para você com ceticismo e perguntarão, incredulamente: “Vovô, você realmente não tinha templates nativos no seu DOM, ou você está de gozação com a gente?” E você dirá: “É verdade, querida Rebeca e pequeno Johnny – agora, vão brincar com seus robôs e não toquem na minha bicicleta atômica”. A seguir, veja um resumo de algumas das principais áreas que estaremos explorando neste livro.

Templates HTML Templates HTML são a simples materialização de um Document Object Model (DOM) modelado, inerte, que pode ser retirado e reutilizado diversas vezes. Antes da tag <template>, havia diversas maneiras de reutilizar HTML. Você poderia escrever suas próprias funções que criavam e preenchiam nós DOM diretamente por meio de métodos DOM, poderia recuperar texto armazenado no DOM por meio de innerHTML e executá-lo através de um mecanismo de template, poderia “pré-compilar” templates na fase de build e enviar funções de template, ou poderia escolher algum outro método igualmente desagradável. Agora, tudo isso acabou. Há uma maneira de escrever HTML reutilizável. Seu uso certamente pode diferir, mas uma coisa é certa: você estará escrevendo seus templates e parciais em tags <template> daqui por diante.

Capítulo 1 ■ Introdução

HTML Imports HTML Imports é outro conceito ridiculamente simples, que acomoda um único ponto de interação para que os pacotes independentes sejam carregados. O que já foi feito para tags <script> e <style> agora está sendo feito para a própria HTML. O bônus, em cima do que foi feito para scripts e estilos, é que a HTML importada pode então ser vinculada infinitamente a todas as suas próprias dependências nos mesmos formatos que já existem. Isso permitirá que um desenvolvedor inclua aplicações em miniatura e todas as suas dependências com um único @include, em vez de seguir no encalço de tudo e incluir todos os códigos-fontes ou links diretamente.

Elementos personalizados Finalmente! Agora existe uma forma padrão de gerar elementos personalizados entre os limites de framework, plataforma e todos os outros. O núcleo da HTML, o elemento único, agora está aberto para todos. A API do elemento personalizado é incrivelmente trivial, e esse é o propósito. Esse é o primeiro passo para montar a HTML naquilo que nossos aplicativos sempre quiseram ser. Isso é muito mais do que simplesmente criar novas tags textuais; é abrir um ponto de contato explícito na API, com o qual todos estejam inerentemente acostumados. É um contrato que já foi combinado, tolerado e apreciado por cada desenvolvedor web que existe.

Shadow DOM Shadow DOM é o ingrediente secreto dos Web Components. Cada uma das outras tecnologias, por si só, agrega valor que é óbvio e apreciado, mas Shadow DOM é o glacê sobre o bolo do componente web. Ele finalmente oferece um modo de isolarmos partes do DOM para obter a verdadeira proteção contra modelagem, acesso e modificação através de meios comuns. Para qualquer um que já tenha tentado criar UIs reutilizáveis, esta é uma mudança bem-vinda, que quase poderia gerar uma lágrima nos olhos do desenvolvedor mais esgotado. Combinando cada uma dessas coisas, temos a capacidade de gerar elementos personalizados, gerando suas próprias subárvores que são isoladas do DOM pai, e todas podem ser importadas por uma única tag! Se, para você, parece que estamos muito entusiasmados, é porque o desenvolvimento com Web Components é como respirar ar puro depois de ter ficado em uma mina de carvão por duas décadas. É como levantar depois de ter retirado um peso de 30 quilos de suas costas. É uma liberdade que é bem-vinda e excitante de verdade.

Desenvolvendo Web Components

Por que Web Components? A Web é um estado transicional, e tem sido assim por muito tempo. Ela foi projetada originalmente para visualizar documentos – é por isso que as aplicações que usamos para examinar seu conteúdo são chamadas de browsers (“folheadores”)! Desde o seu surgimento, no entanto, a Web tem se transformado lentamente em uma plataforma de aplicação, transformando radicalmente o panorama do desenvolvimento de software. Nunca foi tão fácil lançar uma nova versão de uma aplicação: um desenvolvedor publica as mudanças de código ou novos artefatos em um servidor, e o usuário final atualiza a página (como já foi dito, um “refresh” da página é a “compilação” do desenvolvimento web). Infelizmente, o browser não acompanhou essa revolução, forçando os desenvolvedores a surgirem com soluções inteligentes para tornar a Web mais parecida com uma plataforma de aplicação. Os poucos últimos anos viram o surgimento de bibliotecas Model-View-Controller (MVC) em JavaScript e frameworks projetados para ajudar a estruturar as aplicações web. As bibliotecas MVC em JavaScript que foram lançadas nos últimos anos não eram todas estritamente MVC. O acrônimo MV* foi criado para abranger outros padrões, como MVVM (http://bit.ly/ dwc-mvvm) e MVP (http://bit.ly/dwc-mvp).

Carregadores de módulos, como Require.JS (http://requirejs.org/), também ajudaram bastante, oferecendo mais estrutura e suprindo o equivalente (e mais) do import ausente, que é padrão em outras plataformas. Isso permitiu que os engenheiros de front-end pensassem de modo mais modular. Antes da ascensão do MVC, vimos a ascensão de bibliotecas de widgets jQuery e UI. Essas bibliotecas foram desenvolvidas para ajudar a normalizar o desenvolvimento web ao máximo possível e preencher as lacunas no conjunto limitado dos componentes UI disponíveis na Web. Antes dessas bibliotecas, escrever JavaScript que interagisse com o DOM entre os browsers era um pesadelo, e formulários simples eram a única UI com suporte nativo pelos browsers. Se você se afastar e olhar objetivamente para o estado atual do desenvolvimento web, verá que ele é realmente uma brecha gigante – mas isso tem mudado nos últimos anos. O fato de ser uma brecha, de certa forma, não é totalmente ruim. Isso tem dado um sentido de liberdade que outras plataformas e linguagens não possuem. Por mais irritante que possa ser às vezes, é difícil imaginar o desenvolvimento em um ambiente mais restritivo.

Capítulo 1 ■ Introdução

O aparecimento da HTML5 e APIs mais recentes é a evidência de uma grande tentativa de transformar a Web em uma plataforma de aplicação real. Porém, ainda faltam alguns recursos importantes que existem na maioria das outras plataformas de aplicação. Por exemplo, a Web não é extensível. Você não pode criar novos tipos de elementos ou estender os existentes, e não existem imports ou métodos para encapsular componentes. Entram os Web Components. O termo “Web Components” atualmente está sendo lançado da mesma forma que “HTML5”. Os dois termos possuem significados diferentes para pessoas distintas. Literalmente, HTML5 é simplesmente um novo tipo de documento, com mais elementos. Porém, quando as pessoas falam a respeito de HTML5, elas normalmente estão incluindo os novos elementos, CSS3 e as novas APIs JavaScript, que juntos mudam a definição do desenvolvimento web. O mesmo acontece com Web Components – o termo é usado para referenciar uma nova coleção de recursos que, quando utilizados juntos, permitem que os desenvolvedores criem componentes reutilizáveis de um modo padrão. Imagine um mundo no qual a plataforma web seja originalmente extensível. Qualquer elemento pode ser estendido, e novos elementos podem ser definidos para criar facilmente ricas interfaces do usuário. Além disso, imagine um mundo no qual essas extensões possam ser importadas de modo uniforme, incluindo todos os artefatos como JavaScript, CSS e imagens. Imagine que esse sistema tenha sido otimizado para duplicar solicitações para o mesmo import e que os blocos de marcação possam ser carregados e marcados como inertes, de modo a não afetar a performance. Imagine uma plataforma de aplicação real, por assim dizer. Essa é a promessa dos Web Components. E se você pudesse criar um componente de diálogo simplesmente importando o recurso e declarando a marcação significativa? <head> <link rel="import" href="/imports/dialog/index.html"> </head> <body> <dialog-component title="After Ford"> Ending is better than mending. <br /> The more stitches, the less riches. </dialog-component> </body>

Desenvolvendo Web Components

Essa seria uma melhoria enorme em termos de legibilidade em relação ao padrão atual:  <head> <link rel="stylesheet" href="//code.jquery.com/ui/1.11.0/themes/smoothness/jquery-ui.css"> <script src="//code.jquery.com/jquery-1.10.2.js"></script> <script src="//code.jquery.com/ui/1.11.0/jquery-ui.js"></script> <script> $(function () { $( "#dialog" ).dialog(); }); </script> </head> <body> <div id="dialog" title="After Ford"> Ending is better than mending. <br /> The more stitches, the less riches. </div> </body>

Isso não significa dizer que as bibliotecas de widgets atuais não têm algo a oferecer ou que seus padrões são falhos. Na verdade, elas ainda são bastante relevantes, dado o suporte atual do browser para os Web Components. Além disso, a especificação apenas de Web Components não é uma panaceia para a criação de ricas interfaces do usuário. Um componente de diálogo ainda seria guiado pelo mesmo código de um widget de diálogo. Porém, o componente de diálogo envolveria o código do widget em uma interface simplificada, padronizada, nativa, com um método conveniente para a inclusão de suas dependências. Embora esta possa não parecer uma grande melhoria, a capacidade de estender, abstrair, importar e encapsular de forma nativa facilitará bastante o desenvolvimento de aplicações web. Ela permitirá que os desenvolvedores criem elementos reutilizáveis com ciclos de vida padrão, que podem ser importados por qualquer aplicação. Essa padronização formará um contraste implícito entre os elementos e a aplicação, tornando a criação e o gerenciamento de interfaces um processo muito mais estável.