Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Observable ou Promise?

Bom dia,

Tenho entrado mais a fundo nas aplicações com Angular 2 e recentemente me deparei com a seguinte dúvida:

O http do Angular2 me retorna um Observable, mas esse observable "morre" assim que eu tenho um retorno do http. Por mais que eu dê um subscribe nele, é apenas 1 retorno que recebo e tudo se encerra por ali.

Já vi exemplos, até em documentação do Google, de chamadas http que é encadeado o .toPromise() para tornar meu retorno uma Promise. Nesse caso eu usufruiria do .then() ao invés de precisar dar um subscribe.

Eu tenho utilizado Observables na minha aplicação para funções reativas e tudo funciona muito elegantemente. Componentes se increvem nesses serviços e são atualizados em real time.

Mas não entendo porque o http me dá um Observable por padrão. Alguma vantagem de mudar para ele para Promise? Ou existe alguma forma de eu continuar "subscribed" num http para receber notificações futuras? Para isso tenho usado o Socket.io.

Abraço

4 respostas

Oi Yuri! Te respondo assim que chegar no job. É grande a res..pelo smartphone complica.

solução!

Yuri, quando trabalhamos com RxJS, podemos tratar qualquer fonte de dados ou eventos como um array em JavaScript e isso abre espaço para realizarmos transformações mais facilmente. O que dificulta um pouco são os nomes dos métodos que nem sempre são de fácil entendimento.

Não vou entrar em detalhes da API do RxJS, mas você precisa saber que eles são lazy, diferente das promises que são eager. O que isso significa?

Por exemplo, se você abrir seu console do seu chrome e fizer fetch('enderecoqualquernaoprecisaexistir') você estará usando a fetch API do browser que devolve uma promise. Mas verá que já nessa execução ele diz que não foi possível buscar os dados. Isso porque, a promise é eager, ou seja, mesmo eu ainda não tendo acessado o valor resultado em then ela já executa a operação.

Com um Observable a coisa é diferente. Observables são lazy, ou seja, eu posso realizar um map ou qualquer outra transformação com ele, mas ele só executará a operação quando eu realizar um subscribe nele.

Sendo assim, podemos dizer que um Observable posterga ao máximo a execução da operação e isso pode ser interessante em alguns cenários.

Então, pelas funções de transformação e pela sua característica lazy e a capacidade de tratarmos as fontes de dados como um array tornaram o RxJS interessante para a equipe do Angular.

Agora vem o lado negro da força...

Muitos sistemas possuem API's baseadas em promises, até porque esta é a especificação da própria linguagem JavaScript sem termos a necessidade de adicionar bibliotecas ou algo parecido.

É por isso que um Observable possui o método toPromise para transformá-lo em uma promise para poder ser consumida em um chaining de promises. A equipe do RxJS não poderia ter feito diferente, já que promise é difundida ao extremo, justamente por ser parte da especificação JavaScript.

Além disso, há outra razão do Observable permitir toPromise. Uma das grandes features do ES2017 é async/await, algo que vai mudar radicalmente como programamos código assíncrono em JavaScript. A grande questão é que async/await só podem ser usado com promises e não observables!

Então, no final, o desenvolvedor precisa sacar de RxJS e não pode abdicar de promise pelas razões que eu coloquei.

Agora, você esta usando Socket.io para uma conexão persistente com o servidor, nenhum observable por si só fará essa conexão persistente para você.

Ajudei ou compliquei?

Olá,

Excelente explicação Flávio. Ajudou 100%.

Casos como esse confundem bastante quem ainda está se familiarizando com todo esse novo ecosistema.

Agora fiquei mais próximo de me tornar um cangaceiro!

Valeu

Excelente explicação.

A pergunta não foi minha, mas a resposta me ajudou com certeza auhauhahu

Valeu \o