Fork me on GitHub

Grupo de desenvolvedores de PHP do estado de São Paulo
Próximos encontros e eventos? Visite a página do PHPSP no Meetup

[React PHP] Promises e assincronicidade – Parte 1

Por em em Artigos

Em sequência (mais que atrasada) da série sobre React PHP, iremos tratar sobre outra biblioteca do pacote: React\Promise.

Desta vez, eu gostaria de falar um pouco mais sobre a estrutura interna da biblioteca por achar mais didático e menos abstrato. Se isto, na realidade, tornar o tópico mais complicado, não deixe de me notificar com suas dúvidas!

 

Visão Geral

Quase tudo o que vimos até o momento com React PHP trata de rotinas assíncronas. As principais chamadas que fazemos para abrir um arquivo, um socket ou mesmo trabalhar com timers não oferecem resultado imediato: nos permitem esperar por algo que ainda está por acontecer.

Conforme a definição referenciada na página do GitHub do pacote React\Promise, uma promessa – ou promise – é “uma abstração que torna o trabalho com operações assíncronas muito mais agradável”. (clique aqui para ver a definição completa)

O pacote React\Promise traz uma implementação em PHP para o modelo Promises/A . E o primeiro item interessante a ser notado é que este pacote React é um dos poucos que não utiliza o Event Loop.

Os principais conceitos que precisamos trabalhar aqui são os de deferred e promise. Um deferred representa alguma rotina que ainda não terminou de ser executada (assíncrona ou não). E uma promise é a representação do resultado desta rotina. Não que uma promise seja o resultado ao completar um deferred, mas sim a representação encapsulada deste.

 

Instalação da Biblioteca

O pacote React\Promise pode ser instalado através do Composer, basta requerer o pacote react/promise:

Após o download do pacote, adicione em seu arquivo a chamada para o autoload.php e estamos prontos para começar!

 

Utilização Básica de Promises

Eu sei… tá estranho… não contextualizei! Mas desta vez é mais fácil ver o código e depois partir pro conceito, olha aí!

A princípio, quando formos trabalhar com promises, a instanciação ocorre através da classe React\Promise\Deferred e não instanciando manualmente (mais tarde veremos outras opções). A utilização mais básica ficaria mais ou menos assim:

A saída deste código deverá ser algo como…

Agora sim! Vamos analisar o que foi feito!

Primeiramente instanciamos nossa unidade de trabalho e armazenamos numa variavel $deferred. A partir de então utilizamos de seu método promise() para gerar um novo objeto do tipo React\Promise\Promise (não acredite em mim, faz um get_class() aí!). Este objeto é a representação do nosso resultado e nele indicaremos o que deverá ser feito em caso de sucesso e o que deverá ser feito em caso de falha.

No fim de tudo (linhas 20-21), é feita a chamada ao $deferred->resolve('Deu certo')$deferred->reject('Não deu certo...'). Mas por que só o primeiro executou o callback?

 

Estados de uma Promessa

O motivo de somente um callback ter sido executado está contido nos diversos estados que uma promessa pode atingir. Basicamente uma promessa assume somente um estado por vez dentre quatro estados possíveis: não iniciada (LazyPromise), em andamento (Promise), resolvida, com sucesso (FulfilledPromise) e rejeitada, com falha (RejectedPromise).

Ao criarmos uma promessa com $deferred->promise() pode-se assumir que seu estado é “em andamento”, pois a nossa unidade de trabalho ($deferred) foi quem criou o objeto. Ao executar $deferred->resolve($resultadoOK) estamos dizendo que nossa unidade de trabalho terminou de executar e obteve sucesso, neste momento nossa promessa assume o estado “resolvida, com sucesso” e este estado é irreversível! O mesmo ocorre em $deferred->reject($motivoFalha), porém a promessa assume o estado “rejeitada, com falha” e não muda a partir de então.

Exatamente por atingir este estado imutável de “resolvida, com sucesso” a nossa promessa não muda mais de estado ao executarmos $deferred->reject() logo após. Pois uma promessa resolvida (fulfilled) ou rejeitada (rejected) não muda de estado nunca mais!

Como é que este controle de estados é feito? Meu objeto $promise mudou de classe em tempo de execução quando eu a resolvi?

 

Transição de Estados de uma Promessa

O PHP até oferece gambiarras ferramentas que permitem alterar a classe de uma variável em tempo de execução, mas não é o caso aqui. Conforme pode-se notar aqui, a classe Promise possui um objeto interno $result: quando tem valor NULL a promise está em andamento, quando possui um objeto FulfilledPromise a promise está resolvida, e quando possui um objeto RejectedPromise a promessa está rejeitada. Esta organização permite que ao resolver uma promise, esta não seja nunca mais rejeitada e vice-versa. Como? Olha só esse trecho do código fonte da biblioteca:

 

 

Se $result não for NULL a nossa função resolve() nem executa, faz um return e termina ali mesmo.

 

Promises na prática!

Até aqui deu pra sacar o que são as promises e como eles funcionam. Mas pra quê são úteis?

Ainda não vimos um cenário de aplicação das promises. E, realmente, está bem fora do que estamos acostumados a ver com PHP. O próprio ambiente que React PHP provê está um tanto fora da nossa zona de conforto. Mas para nossa alegria, há uma outra biblioteca React PHP que se utiliza de promises de um jeito muito simples. Dá uma olhada no que o React\Stomp faz:

 

 

Numa outra oportunidade lhe explico melhor o que este código está fazendo. Por enquanto, atente-se somente à ideia de que $client quer se conectar à um serviço remoto e esta comunicação é assíncrona. Adivinhe o tipo de retorno de $client->connect()… EXATO! React\Promise\Promise!

A maior ideia de usar promises é permitir que você diminua o acoplamento do seu código assíncrono e utilize menos callbacks. É natural que o número de callbacks cresça (muito) conforme a complexidade do seu programa e o código vai ficando cada vez mais difícil de ler e dar manutenção. Além disso, adota-se uma semântica muito mais agradável ao seu código, só de ler podemos inferir o que está acontecendo. Note a diferença:

 

 

Muito mais fácil de imaginar e prever o que acontecerá em vez de…

 

 

Pois no último exemplo você tem de conhecer muito bem as classes Nawarian\FileOpenerNawarian\HttpNavigator para saber que $fileHandle emite eventos com os nomes openerror, que $page emite os eventos openfail e, além disso, tem de saber o que cada evento quer dizer na realidade. Concorda?

 

Promessas como Interface de Programação

Não bastasse a utilidade natural das promessas, ganhamos ainda um bônus de desacoplamento mesmo se não utilizarmos código assíncrono. Imagine um cenário onde precisemos inserir um usuário no sistema. Como o faremos? Inserção no banco de dados? Webservice? Gravar num arquivo? Para quem utiliza o nosso código tanto faz a implementação se a gente usar promises como retorno, basta respeitar a interface. E, para nós, trocar a implementação é relativamente trivial:

 

 

Conclusão

Vimos aqui o básico da biblioteca React\Promise, como trabalhar com ela e também alguns cenários de utilização. Deve-se notar que por respeitar ao padrão Promises/A sua utilização não é muito diferente de o que vemos em bibliotecas JS como AngularJS ($q), kriskowal/q ou mesmo no jQuery.

Ainda há tópicos que não abordamos, como as Lazy Promises, encadeamento e funções utilitárias. Vou poupá-los (a você e aos tópicos) para um segundo texto, que este aqui já está literalmente de bom tamanho.

Tags: , , , , , , ,

Sobre Níckolas Silva

Desenvolvedor php há aproximadamente 6 anos, Níckolas é tecnólogo em Análise e Desenvolvimento de Sistemas, pós graduado em Engenharia de Software com foco em SOA e já esteve envolvido com desenvolvimento de sistemas de telecom e de gestão. Hoje dedica horas de seus dias ao estudo de tecnologias, práticas e técnicas sobre sistemas distribuídos, procurando integrar todas as áreas de atuação através destes estudos. Além disso está presente em todos eventos PHPSP+Pub, pois acredita que conversas, pessoas e cerveja são a chave para aprender e fortalecer conceitos.

Mais posts de .