Para a melhor abordagem para projetos Angular, Observable ou Promise ?

Assuntos Gerais Notícias
#1

Tenho feito projetos com o FrameWorks Angular, e geralmente uma API do angular é dividido por componentes, serviços e modulos.

Nos serviços é onde será incluido os métodos http, como inserir, atualizar e deletar registros de uma API Back-End, me perdoe se caso eu tenha feito alguma explicação errada do que acabei de afirma, é porque ainda estou aprendendo.

Nos serviços os projetos podem utilizar duas abordagens para os métodos, pode ser usado a abordagem de Observable ou Promise, como podem ver no exemplo abaixo;

pesquisar(): Promise<any> {

    const headers = new Headers();

    return this.http.get(`${this.noticiasUrl}`, { headers })
      .toPromise()
      .then(response => response.json().content);

  }

Abordagem com Observable

restaurants(search?: string): Observable<Restaurant []> {
        return this.http.get(`${MEAT_API}/restaurants`, {params: {q: search}})
        .map(response => response.json())
        .catch(ErrorHandler.handleError);
    }

Então essas são minhas dúvidas;

  1. Qual é a abordagem mais utilizadas no mercado de trabalho?
  2. A utilização vai depender do projeto?
1 curtida
#2

Ambas são bastante utilizadas, depende do caso, da situação e do que você realmente quer fazer.
É interessante ler a documentação e identificar os casos em que cada uma das abordagens é mais indicada.
Ah, particularmente eu prefiro trabalhar com Promise, posso estar enganado, mas me parece mais flexível.

#3

Dependendo de que caso?
De que situação?

Eu fiz a pergunta não foi para chegar aqui e alguém ter que me sugerir de estude a documentação, assim fica muito fácil, eu simplesmente entro no site do GUJ, vejo a dúvida de uma pessoa sobre Angular, como eu acho que a pessoa não estudou o suficiente, eu simplesmente digo pra ele estudar mais e se virar numa documentação que não tem tudo explicado esplicidamente, sabendo que eu poderia fácilitar a vida da pessoa e dá meu ponto de vista em relação ao tema porque as vezes a experiência de trabalho é muito mais importante do que a documentação de tecnologia X, Y e Z.

Realmente não tinha visto a documentação e tive que ler a documentação para te dá essa resposta, porque mesmo lendo a documentação não conseguir saber porque existem tantos projetos no GitHub com as abordagens do Observable do que com Promise, porém eu aprendi a fazer os meu projetos com Promise.

A explicação é essa!

O Observable é geralmente utilizado quando os formulário terão também abordagens de Reactive Forms, é uma foma de programação reativa, ou seja, um eventos acontece e os que estão interessados são notificados e reagem a ele, a ideia é baseado em eventos, ai que entra o Observable, é um padrão de projeto.

Em Reactive Programming que é um padrão de projeto que utiliza o Observable é um recurso que interage com registros de forma minuciosa, ele contém uma serie de funções e operadores para inscrição e manipulação de eventos de um Array.

O Promise se comporta da mesma forma, a única diferença é que o Observable ainda continuar disparando eventos até que sejam esplicidamente fechados, e já Promise são considerados resolvidos depois do primeiro evento.

Isso está na documentação do Angular, a abordagem de Observable e totalmente diferente do Promise, o Observable é um recurso nativo do Angular e o Promise e uma novidade do Angular.

Se o Promise é uma evolução do Angular porque será que nos projetos são tão usados o Observable?

Eu acho que foi interessante te me incentivado a estudar o assuntos pela documentação, mas ter me sugerido a estuda a documentação não ajudou a tirar minhas dúvidas.

O mercado de trabalho utiliza mais Observable justamente porque ele é um recurso nativo do Angular?

1 curtida
#4

Não sei de onde você vem, nem quem você é.
Acontece que a documentação, de qualquer linguagem ou api é o primeiro ponto para esclarecimentos de dúvidas.
Você pode até ser autodidata e aprender boa parte de como se desenvolve em uma linguagem como Java ou PHP ou mesmo em algum framework javascript, porém, cedo ou tarde, precisará recorrer à documentação para ter um entendimento maior sobre o que está fazendo e como está fazendo.
Por exemplo, eu sei que a diferença entre eles é que o observable é lazy (preguiçoso) e o promise é eager (apressado). Como assim? Basicamente, o promise executa uma ação de imediato, enquanto que o observable aguarda o retorno de alguma coisa para, então, executar sua ação.
Esta thread (que facilmente se encontra numa rápida pesquisa no google) tem, como segunda resposta (a primeira apenas diz para esperar que ele vai responder), um detalhamento bastante esclarecedor sobre como cada um funciona.
Se não for pedir muito, poderia ler para entender o que eu digo.

Aliás, a sugestão para que leia X ou Y tem a finalidade de permitir que qualquer um, não apenas você, possam ir além do lugar comum. Sempre que eu leio, o que quer que seja, acabo me interessando por outras cosias que encontro no texto. Por exemplo, na thread que citei, ele comenta sobre a especificação RxJS. Como eu conhecia quase nada dela, resolvi ir atrás, entender;

Bons tempos quando o GUJ era feito de respostas do tipo “já leu a documentação?”. Pena que as pessoas se sentem ofendidas quando isso acontece, hoje.

#5

tudo bem, me desculpe o jeito que falei, porque mesmo assim lendo a documentação eu não entendi muito bem, mas eu tinha que ter uma conclusão sobre tudo que li, e pelo que entendi, o Observable vai do jeito mais detalhado, porém sem necessidade já que existe o Promise que faz de um jeito Pratico e rápido, eu acho que a maioria das empresas querem usar a abordagem do Observable pelo fato que Promise seja abordagem de algo novo, e as pessoas tem medo de mudanças, mas quando você falou que vai depender de cada caso e situação ai eu fiquei confuso.

Que tipo de situação são mais usados o Promise? Em que casos são usados o Observable? Eu não encontrei isso na documentação, não serei pretencioso ao ponto de dizer que isso não existe na documentação porque as vezes eu tenho pouca atenção.

#6

Cara se não pode ajudar , não tem conhecimento suficiente para isso, não fique com estas respostas chucras de ler a documentação e pesquisar, isso todos ja fazem, o que o sujeito acima precisa e de uma opinião profissional, de um parecer de alguém que tem experiência no assunto, e não é o seu caso. Pare de ficar respondendo qualquer coisa só pra ganhar notoriedade. Cara chato e de conhecimento pífio.

1 curtida
#7

@Kleristron, é teu nome mesmo?
Qual das respostas foi de mais valia, a minha ou a tua? Ah, sim, você é da patrulha do mimimi, né? Acha que tentar intimidar quem responde de uma maneira que você não espera é o máximo, não?
Não vi você responder nada, não vi acrescentar nada ao tópico.
Aliás, nunca te vi aqui. Você é quem, mesmo?

4 curtidas
#8

kkkkk eita nós. :stuck_out_tongue:

#9

Esse @Kleristron é o mesmo cara dos tópicos abaixo:

:joy::joy::joy::joy::joy:

1 curtida
#10

É meu ponto de vista.
Não acredito que o @Kleristron esteja totalmente errado no que disse, e também não acredito que você, o @darlan_machado esteja totalmente certo em tudo que falou nessa postagem que fiz, eu pessoalmente sou contra qualquer forma de agressividade em coisas escritas nesse fórum, porque nos encontramos entre pessoas muito esclarecidas e agredir pessoas aqui no fórum é um retrocesso, eu mesmo já fiquei MUITO chateado com algumas pessoas aqui no fórum, mas existem outras formas de conseguir argumentar, por outro lado afirma como você afirmou como mostra abaixo que a explicação estava na documentação foi bem apelativo, porque você afirmou passando a maior segurança do mundo que a resposta para minha pergunta estava na documentação, e de fato, não estava.

Veja que vou responder minha própria pergunta;

Depois que postei isso aqui no fórum tive a oportunidade de conhecer algumas pessoas no Linkedin que trabalha com um pouco mais de 3 anos com essa tecnologia, ele me respondeu mais ou menos assim

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.

Era mais ou menos a resposta que o @darlan_machado se tive boa vontade de ajudar teria dado, a explicação ele até deu, e estava dentro do contexto da explicação que dei logo acima, mas foi necessário eu afirmar para ele que não estava na documentação.

Mas ele diz o seguinte argumento!

Eu não fiquei ofendido em pedir para eu estudar a documentação, mas eu fiquei chateado em você ter dado toda a segurança de que a resposta para minha pergunta estava na documentação, e de fato, não estava

A resposta realmente só conseguir com pessoas que trabalham com isso, eu sei que o @darlan_machado estava tentando me ajudar, não acredito que ele esteja

Tentou ajuda, e ele realmente ajudou, mas só depois que eu argumentei dizendo que não tinha na documentação.

Eu já encontrei pessoas aqui que são verdadeiras perolas que vieram do Iraque, elas aparecem aqui preparados para qualquer guerra, e o @darlan_machado é um cara legal, eu vi as postagens mais antigas dele, e em muitos casos ele consegue ajudar.

O @darlan_machado só não pode aceitar que o @Kleristron venha aqui com palavras agressivas e deixe por isso mesmo.

Eu não estou puxando saco de ninguém, eu acredito que todos os comentários foram validos, e não concordo que quando você não conhece alguma coisa você sugeri para a pessoa buscar a documentação sem ter certeza que está na documentação.

Porque se realmente estivesse na documentação, o esforço que fiz de ler a documentação iria ser valida, mas como não estava na documentação a explicação explicita pareceu mais um trote.

Mas está tudo certo, e acho que as contribuições foram importantes.

#11