Roteador UI Angular e Componentes

Roteador UI Angular tem vindo a integrar lentamente o suporte de encaminhamento para componentes angulares. Este post irá discutir porque isso é útil, e como fazê-lo usando ambos Angular UI Router 0.x.x e 1.0.0-beta.x versões.

Background

Com a introdução dos componentes Angulares na versão 1.5, o conceito de um conjunto autônomo e reutilizável de comportamentos e visões tornou-se mais fácil de definir do que anteriormente feito nas diretivas. Estas mudanças incluem: abstraindo escopo, vinculando explicitamente aos controladores, fornecendo ganchos de ciclo de vida no controlador, assim como algumas outras coisas.

Isso permitiu uma melhor componentização de vistas e aplicações inteiras. Com isso veio a percepção de que uma página web é um componente composto de componentes.

Posto isso, o roteamento para um componente tornou-se um comportamento desejado.

Smart vs Dumb Components

Antes de se aprofundar no uso do Roteador UI para rotear para componentes, o conceito de componentes inteligentes e burros deve ser discutido.

Um componente inteligente é aquele que está muito ciente da API e dos dados que conduzem uma visualização. Isto significa que em seu controlador, ele normalmente está fazendo uma chamada de serviço na inicialização do componente. Ele sabe o que é necessário para fazer a chamada e a resposta que deve esperar da API.

Por outro lado, existem componentes burros que sabem o que fazer com um objeto ou valor passado e por quais interações ele é responsável. Ele normalmente não interage com nenhum serviço. A maioria das interações resulta em uma chamada de retorno para um componente pai para passar informações de volta para ser usado
por um componente inteligente ou estão relacionados puramente a mudanças de exibição.

Para o bem da reusabilidade, componentes burros tipicamente são os mais reutilizáveis (pense em containers com cabeçalhos, barras de navegação, caixas de seleção, etc). Componentes inteligentes são ótimos para construir aplicações completas a partir de um alto nível, mas não são muito personalizáveis.

A melhor maneira de tornar um componente burro é remover as chamadas API dos controladores e encontrar uma maneira de fornecer esses dados através de algum tipo de encadernação. Isto é útil se você já tem os mesmos dados que um componente inteligente precisa, mas não quer fazer dois cliques no servidor para isso.

Escrevendo uma aplicação como um componente

Com a mudança para aplicações componentizadas, houve uma mudança de mente relacionada a como nós vemos as aplicações. Aplicações inteiras podem ser vistas como um componente. Isto na verdade tem casos de uso prático. Por exemplo, se escrevermos nossa aplicação como um componente, podemos tomar uma aplicação web independente e potencialmente colocá-la em um container web híbrido e fazer uma aplicação móvel a partir dele.

A melhor maneira de escrever uma aplicação como um componente é tirar vantagem das vistas aninhadas no Roteador UI. Isto pode ser desafiador, às vezes, mas permite grande flexibilidade na troca de componentes baseados em
no estado da aplicação.

Uso de Componentes em Definição de Estado usando Template

A primeira integração com componentes roteáveis foi, em vez de usar uma propriedade templateUrl na definição de estado, foi usar a propriedade template, em vez disso. Um exemplo disto seria como
follows:

Obviamente, isto funciona, mas quando cada estado é declarado com um elemento HTML que é simplesmente um único elemento HTML sem atributos, ele começa a ficar enfadonho.

Granted, toda a lógica e exibição relacionada a esse componente é isolada e reutilizável. Se, por exemplo, você decidir envolver myComponent em um template de navegação, agora você pode fazer isso sem ter que gerar um novo componente a partir de um template se você tivesse configurado o mesmo estado como tal:

Binding to Components

Como nós escrevemos uma aplicação completa como um componente burro, quando muitas de nossas rotas precisam fazer chamadas de serviço para exibir informações que um usuário quer ver?

Uma resposta possível a isto é resolver os dados necessários para o componente funcionar a partir da rota e depois ligá-lo ao componente através dos bindings do componente. Há duas abordagens para fazer isso:

1. Criar um componente inteligente que envolva um componente burro. O único propósito do componente inteligente é fazer uma chamada de serviço e fazer a ligação adequada ao componente burro.
2. Utilizar a funcionalidade de resolução fornecida no roteador UI para resolver dados diretamente para o componente burro.

Existem algumas trocas óbvias para ambas as opções. Com um wrapper de componente inteligente, você tem um componente adicional para manter. Para resolver o componente usando o roteador UI, você está se ligando à habilidade do roteador, e também é mais difícil gerenciar o tratamento de exceções.

Dito isto, criar componentes roteáveis através dos bindings do Roteador UI é extremamente simples, e o Roteador UI é poderoso o suficiente e fornece uma grande funcionalidade a ponto de, se estiver em seu projeto, provavelmente permanecerá lá até uma reescrita completa de um aplicativo.

Para bind a um componente na versão estável do Roteador UI (0.x.x), o Roteador UI cria um objeto $resolve no contexto que ele usava para compilar o conteúdo do componente ui-view.

Isso pode ser usado para bind a uma declaração de componente na propriedade template da definição de estado.

Isso nos permite remover a dependência UserService do componente user. Para aqueles componentes inteligentes que simplesmente fazem uma chamada de serviço e depois exibem a informação, nós podemos realmente eliminar um controlador inteiro, assim como.

Binding to Components – 1.0.0-beta.x

Com o lançamento de [email protected], a propriedade component foi adicionada ao objeto de definição de estado. Isto permite que o desenvolvedor se ligue diretamente a um componente como definido no módulo angular. Ele elimina a necessidade de ter um template contendo um único elemento, como já vimos no passado.