Coletando dados do Pieces

Uma grande mudança aconteceu a alguns anos na maneira como escrevemos aplicações web. Na web dos anos 90, até meados do final dos anos 2000, uma página da web era um único documento, principalmente texto e imagens estáticos. Se quiséssemos fornecer uma experiência mais interessante aos usuários, tínhamos que criar várias páginas e conectá-las com hiperlinks. Era uma época tranquila onde os GIFs eram legais e escrevíamos aplicações .NET em MVC com quase nada de JavaScript.

Tudo isso mudou, e para algo muito melhor, com a chegada das aplicações de página única (single-page applications, ou SPA). Agora, os dados exibidos na página podem ser alterados durante o tempo de execução da aplicação sem recarregar a página e as solicitações HTTP por de trás, nos permitem buscar dados do servidor de acordo com os dados de entrada do usuário, possibilitando uma maior interatividade.

Há um aspecto das páginas da web tradicionais que não está muito claro se tratando do mundo dos SPAs, que seria o que acontece com a URL exibida na barra de endereços? Para aplicações tradicionais, o endereço identifica a página que estamos visualizando no momento. Para os SPAs, o endereço não muda automaticamente, mesmo quando alteramos a parte da aplicação que estamos visualizando. Para não perder a capacidade de vincular partes específicas do site, é necessário algum mecanismo para alterar a URL à medida que navegamos pela aplicação e encaminhamos o usuário para uma parte específica dela, de acordo com o que está digitado na barra de navegação.

Isso nos leva à questão relacionada das transições de página. As transições entre páginas web tradicionais eram feitas recarregando a página inteira. O navegador ficaria em branco por um momento e precisaríamos aguardar que tudo fosse atualizado na tela, o que não é uma experiência boa para o usuário. As aplicações de página única não apenas tornam as transições muito mais rápidas, mas também, abrem algumas possibilidades totalmente novas. Ao invés de substituir uma parte da página por outra, por que não animar a transição entre elas? Deslizamento, desbotado e outras animações são possíveis quando o JavaScript está no controle da página web.

O Pieces, uma nova biblioteca JavaScript que foi criada por Martin Rixham, autor deste texto, resolve os dois problemas juntos, de roteamento e de transição de páginas. Afinal, ambos os problemas estão preocupados com o que acontece quando a aplicação muda de uma página para outra. A ideia é que o desenvolvedor crie as páginas individuais e que o Pieces se preocupe com tudo o que está envolvido na mudança entre elas.

O Pieces depende de uma biblioteca de ligação de dados chamada Datum (Caso queira saber mais sobre ela, consulte o artigo de introdução do Datum e o guia de início rápido do Datum). O Datum é uma biblioteca pequena, mas muito bacana, capaz de criar SPAs por conta própria, mas deixa sem resposta as questões importantes de roteamento e transições de página. O Pieces fornece uma possível resposta para essas perguntas.

É importante lembrar que nem o Datum nem o Pieces são web frameworks. São apenas bibliotecas separadas, onde cada uma tem um objetivo específico, que resolve um problema específico. Eles não estão totalmente integrados, ou seja, o Pieces precisa do Datum, mas o Datum não precisa de nenhuma API específica para ajudar o Pieces a fazer seu trabalho. Embora o Pieces pretenda fazer seu trabalho focando em um espectro mais amplo para poder ser aplicado à maioria das aplicações web, ele toma algumas decisões sobre o comportamento do site que não estão em conformidade com a opinião de todos os desenvolvedores. Se formos uma dessas pessoas, o Datum poderá ser utilizado sozinho ou em conjunto com uma biblioteca alternativa.

No Datum, os componentes da aplicação são apenas objetos JavaScript. O Pieces espera criar componentes como objetos usando o Datum e depois passá-los ao construtor de uma peça de navegação que o Pieces fornece. A peça de navegação que escolhermos determina o tipo de comportamento de navegação que a aplicação terá. As próprias peças de navegação também são apenas objetos JavaScript, então podemos adicioná-las ao modelo de exibição de acordo com o local em que devem aparecer na página.

A maioria das peças de navegação possuem a mesma interface. Um exemplo simples seria algo como o código abaixo, que representa uma animação de desbotado entre três páginas e alguns botões para acionar a transição:

function Fade() {
    this.onBind = function(element) {
        $(element).load("html/fade.html");
    };
    // Cria um container de navegação com páginas e as respectivas rotas.
    this.content =
        new FadeNavPiece([
            { route: "one", page: new FirstPage() },
            { route: "two", page: new SecondPage() },
            { route: "three", page: new ThirdPage() }
        ]);
    // Botões de navegação
    this.one = new NavButton(0, this.content);
    this.two = new NavButton(1, this.content);
    this.three = new NavButton(2, this.content);
}

A propósito, essa transição de desbotamento vai e volta simultaneamente, o que não é um truque fácil de se conseguir!

A navegação em slides é semelhante à navegação de desbotamento, exceto que a animação será um movimento de deslizamento horizontal ao invés de sumir e aparecer. A parte do scroll da navegação é um pouco diferente nas partes desbotadas e deslizantes, pois todas as subpáginas serão exibidas imediatamente uma abaixo da outra. A animação apenas faz o scroll da página para cima e para baixo nos componentes apropriados.

O Router Piece não possui nenhuma animação associada. Ao invés disso, existe um ponto de extensibilidade. Se o Pieces não fornecer algum comportamento imediato, provavelmente poderá ser implementado usando o Router Piece, que usa apenas um componente como parâmetro e procura uma propriedade chamada route. O valor da propriedade route é o que aparece no caminho da URL. Se a propriedade for atualizada, a URL será atualizada e, se a URL for alterada, a propriedade route poderá ser alterada. Qualquer funcionalidade que dependa do valor da propriedade route será sincronizada com a URL. Este exemplo exibe uma imagem de um animal de acordo com o animal que o Router Piece encontra na URL.

function Router() {
    // O Route Piece procura por uma propriedade chamada route.
    this.route = "";
    this.onBind = function(element) {
        // Carrega o template.
        $(element).load("html/animalTemplate.html");
    };
    // A atualização do callback é chamada quando o animal é atualizado.
    this.image =
        new Update(function(element) {
            // Mostra a imagem.
            element.src =
                "images/animals/" + this.route + ".jpg";
        });
    // Coloca o objeto no Router Piece.
    return new RouterPiece(this);
}

Agora vem a parte divertida: O aninhamento. O caminho de uma página web geralmente não é apenas uma palavra, mas uma lista de palavras como /caminho/para/minha/pagina/web. Igualmente, a página de um SPA pode conter seus próprios elementos de interatividade e até as próprias subpáginas. O Pieces combina automaticamente as rotas das peças de navegação aninhadas em um caminho. Não somos obrigados a usar um estilo de navegação para toda a aplicação. Aninhando os objetos de navegação, diferentes partes da aplicação podem usar transições diferentes. Talvez a navegação superior esteja deslizando entre as páginas, mas uma delas pode exibir as informações de uma maneira interessante, desvanecendo-se entre diferentes trechos de texto. O Pieces conectará as rotas desses diferentes elementos em uma rota, para que diferentes partes da aplicação possam ser facilmente vinculadas.

Podemos combinar os dois exemplos acima, tendo uma navegação superior desbotada e nosso exemplo animal como uma das páginas.

new FadeNavPiece([
    { route: "one", page: new FirstPage() },
    { route: "two", page: new SecondPage() },
    { route: "three", page: new ThirdPage() },
    { route: "router", page: new Router() }
]);

Nesse caso, podemos ver um gato escrevendo #router/cat no final da URL.

Isso nos fornece tudo o que precisamos para criar os SPAs. Provavelmente, também precisaremos de uma biblioteca de widgets de UI (interface do usuário) e talvez de mais elementos para validação dos dados e outras funcionalidades, mas a mecânica de organizar componentes em uma página web e fazer a transição entre elas está aqui. Para outras bibliotecas, existem várias opções disponíveis que são excelentes e as que não são específicas para uma estrutura única devem funcionar bem nesse contexto. Poderia ter muito mais a dizer sobre o design das aplicações web, mas não vou falar muito sobre esse assunto. Vale ressaltar que, se estamos acostumados com o estilo MVC de design de aplicação, o que vimos será bem diferente. Seria possível criar objetos separados do model e dos controllers e lidar com os objetos que utilizamos acima como sendo a view, mas isso provavelmente seria um exagero, especialmente se houver um modelo dos dados do lado servidor. Podemos simplificar e usar objetos como os de nossos exemplos para representar todo o estado da aplicação web, porque há flexibilidade suficiente nesse tipo de model com view para lidar com quaisquer diferenças entre como recebemos dados do servidor e como eles são exibidos na página.

Motivação

O objetivo do autor na criação do Pieces foi mostrar que as pesadas web frameworks não são a única solução para o desenvolvimento fácil de aplicações. Um recurso conveniente, como roteamento totalmente integrado e transições de página, é possível com uma simples biblioteca. Alguns dos frameworks atuais são muito pesados ou são uma grande coleção inconsistente de recursos sem nenhum design, negando os benefícios da estrutura.

Os sistemas projetados como pequenas peças flexíveis formam a base para a construção de uma estrutura leve própria. Vemos essa tendência com ferramentas modernas como o Svelte, Dojo, Preact e outras mais, além do Pieces que segue essa mentalidade de fazer uma coisa bem feita com total foco à ela, sem tentar ser tudo para todo mundo.

O Pieces não é a ferramenta certa para todas as aplicações web que criamos, mas é uma boa opção para muitas aplicações além de ser uma vantagem para quem não deseja lançar um módulo de roteamento e transição de página. Com pequenos módulos flexíveis, podemos optar por usá-lo ou não. Esse é o X da questão!

No debate ainda ativo sobre o uso de web frameworks ou frameworks nativas para aplicações móveis, há grande tentação em escolher ambientes integrados, fornecidos pelo iOS e pelo Android. Os desenvolvedores podem não querer gastar tempo reinventando a funcionalidade comum entre as aplicações, por isso tendem a escolher plataformas que fornecem grande funcionalidade já pronta para uso. Aprender a ser produtivo em uma nova plataforma pode parecer assustador para desenvolvedores que não possuem muita experiência, portanto, a tentação é facilitar a vida deles, fornecendo todas as principais ferramentas necessárias em um só lugar. Depois que adquirem a devida experiência, os desenvolvedores começam a se perguntar, com razão, o motivo pelo qual são forçados a fazer as coisas da maneira que dizem que é para ser feita. Parece haver uma desvantagem em que quanto mais tentamos fornecer ferramentas aos desenvolvedores para dar aquilo que precisam, mais criamos um ambiente altamente acoplado que restringe suas escolhas. O desafio é dar a este pessoal algo realmente útil sem restringir as escolhas de como fazer qualquer outra coisa. Acredito que isso seja possível, embora exija uma reflexão cuidadosa sobre a maneira como diferentes componentes de uma aplicação web interagem.

A questão da dissociação deve ser particularmente preocupante quando estamos falando do mundo web, pois não existe vantagem de ser cuidadosamente projetada por uma única empresa da mesma forma que nas demais plataformas. A web é mais um esforço colaborativo com diferentes tecnologias que se provaram ao longo dos anos, serem melhores do que outras. De acordo com Martin Rixham é comum pensar que a web está mais focada para este lado. No final, ele acredita que não haverá mais pessoas escrevendo bibliotecas para a web, mas teremos a vantagem de mais abordagens e perspectivas adicionadas à mistura. Acredito que isso deve influenciar a maneira como escrevemos as bibliotecas. O ideal seria ter uma seleção de bibliotecas desacopladas que podem ser usadas ou não, de acordo com o gosto do freguês, ou do desenvolvedor, neste caso. Aqueles que desejam muita ajuda podem optar por bibliotecas maiores e completas, e aqueles que desejam uma personalização maior, podem usar as menores, mas estaríamos todos trabalhando no mesmo ambiente ao invés de termos cada comunidade desenvolvendo para sua própria panelinha.

Alguns dos desafios são escolher as abstrações corretas e promover as APIs fundamentais para evitar duplicação entre os módulos. Por exemplo, antes que as promessas e os módulos fossem padronizados, havia um trabalho significativo para fazer com que diferentes bibliotecas funcionassem de maneira consistente com padrões e módulos assíncronos. Talvez a Biblioteca Padrão do JavaScript que foi proposta, possa ajudar ainda mais na briga entre plataforma versus módulos ou frameworks.

Definir claramente a interface entre JavaScript e HTML é uma abstração valiosa e, com o Pieces, a abstração foi utilizada para separar os elementos visuais de uma aplicação, do comportamento que conecta esses elementos visuais. Espero que isso ajude os desenvolvedores a escrever aplicações, mas também espero que inspire os criadores de bibliotecas a criar bibliotecas mais abstratas e dissociadas que aumentarão ainda mais o poder da web.

Pieces é um software de código aberto disponível sob a licença LGPL versão 3. Visite piecesofdata.com para começar a usar o Pieces.

Sobre o autor

Martin Rixham trabalha com consultoria de TI, aplicando anos de experiência em desenvolvimento web e várias linguagens JVM. Ele divide seu tempo entre Londres e Bangalore, onde tem o privilégio de fazer parte de duas grandes comunidades de TI.