Ember: Comunicação entre componentes distantes

Recentemente tive a necessidade de compartilhar contexto e informação entre componentes, o problema principal era que ambos os componentes estavam em contexto completamente diferentes, complicando o compartilhamento de informação. Além disso o modelo DDAU tem se mostrado bastante complexo quando se tem diversos níveis de componentes.

Esse artigo é basicamente uma tradução com algumas adaptações do artigo (Communication Between Distant Components).

Vamos lá…

Componentes são entidades isoladas sendo que a integração/interação é através do contexto que os envolvem.

O Data Down, Actions Up pattern é hoje uma das melhores práticas para realizar comunicação entre componentes. (Para saber mais)

Componentes enviam ações (mensagens) para cima através da sua sendAction API, se houver mudança ele renderiza os dados. Essas ligações são geralmente "um caminho" (imutável) para que os dados não serem modificados localmente (Como ocorre no modelo two way data binding), mas receberem uma cópia da informação.

{{my-component item=model action='navigateTo'}}

Existem esses tipo de comunicação:

• Para cima para outro objeto Ember (route, component, controller, etc)
• Descendo: Componentes filhos ou aninhados
• Lateral: Componentes sem hierarquia ou em contexto completamente diferentes

As setas azuis representam os dados e as setas roxas representam as ações. Essa regra se explica a todos os componentes. Se o componente mais profundo na hierarquia precisar enviar uma mensagem para cima, ele terá que enviar uma ação. A ação deverá ser encaminhada componente a componente até atingir o destino.

Vamos supor que o diagrama acima representa uma parte de nossa aplicação no mundo real. Uma aplicação que consiste em mais de 50 componentes.

O componente verde é um novo widget responsável por mostrar o log das atividades de todo o site. Pode ser utilizado dentro de qualquer componente, várias vezes, se necessário.

Como exemplificado com seta tracejada no diagrama, como seria a comunicação?

Data Down, Actions Up

Como foi dito antes, componentes se comunicam através da interface. A assinatura de nosso widget, poderia ser dessa forma:

{{activity-widget feed=feed}}

O que significa que todos os componentes que usam activity-widget devem fornecer um objeto feed. Isso inclui todos os componentes pai e filhos até que feed chegue ao nosso componente respeitando a abordagem Data Down, Actions Up.

Isso exigiria uma hierarquia que tende a ficar complexa e difícil de dar manutenção. No nosso diagrama essa ação teria que percorrer vários níveis até conseguir realizar a mudança.

Proposta…

Um vez que temos nosso componente: activity-widget

• Ele pode ser inserido em qualquer componente
• Ele não pode depender de uma route para fornecer dados

Com essas regrinhas, vamos começar!

Será super fácil com Ember! Vamos começar criando um FeedService que deve herdar Ember.Evented, um mixins da acesso a métodos como on, off, trigger.

Essa abordagem é extremamente útil para fornecer uma camada de comunicação ente componentes.

É importante notar que o exemplo não representa um cenário real. Além disso a comunicação poderia ter sido resolvida utilizando abordagem Data Down, Actions Up, usando a interface de comunicação através de assinatura de componente. Outro ponto importante é entender que mesmo usando essa abordagem o componente continua com baixo acoplamento, porém um pouco mais complexo para o entendimento da comunicação.

Ajude a comunidade Ember crescer. Compartilhe nosso conteúdo ❤

Esse texto é parte de uma iniciativa da comunidade EmberJS Brasil, que busca disseminar conteúdo sobre Ember, que seja de qualidade, autoral ou traduzido. Sigua nosso Twitter! e parcipe da comunidade global de Ember no Slack! E acesse o canal: #lang-portuguese!

Você manja de Ember, que escrever com a gente?

Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.