Portas e ligações

Compreender as portas é compreender quando uma caixa se executa. Esta página é a referência do modelo.

As três portas implícitas

Toda a caixa as possui, sem que apareçam na sua configuração:

Porta	Sentido	Fluxo	Função
in	Entrada	Sinal	Acionador. Várias ligações de entrada aceites
error	Saída	Valor + sinal	Rota de falha
done	Saída	Sinal	Emitida após a conclusão da caixa e de todo o seu subgrafo a jusante

Três caixas não têm porta error: Saída, Agora e Retry (esta última é ela mesma uma fronteira de erro). Duas não têm done: Saída e Throw.

Tipos de fluxo

Fluxo	Símbolo mental	Comportamento
Valor	Um dado	Transporta um valor; serve também de acionador
Sinal	Um impulso	Não transporta nada, apenas aciona
Ambos		Transporta um valor e aciona

A única combinação proibida: uma saída de sinal puro para uma entrada de valor puro. Não haveria nada para pôr no valor.

Tipos de dados

any · json · number · string · boolean · duration · response · status · list · object.

A tipagem serve sobretudo para o conforto visual, com uma exceção estrita: uma entrada de tipo lista (a porta list das ações Adicionar à lista e Remover da lista) recusa uma origem que não seja compatível com lista. json e list são compatíveis entre si; um object simples não o é.

Aridade

• Uma porta de entrada aceita apenas uma ligação. É o que torna o grafo legível: um valor, uma proveniência.
• Exceto in, que aceita tantas ligações quantas se queira.
• Uma saída pode alimentar tantas entradas quantas se queira.

Quando é que uma caixa se executa

Três regras, por ordem:

1. As raízes arrancam. Toda a caixa sem ligação de entrada é iniciada no lançamento do cenário. Não existe uma caixa “de partida”.
2. Só as entradas ligadas são esperadas. Uma caixa executa-se quando cada uma das suas portas de entrada efetivamente ligadas recebeu um valor. Uma porta não ligada nunca é esperada. Os valores ficam memorizados: uma entrada conserva o último valor recebido.
3. A porta in faz barreira. Alimentada por várias ligações, espera que todas tenham chegado e aciona então uma vez. É o “esperar que estes três ramos terminem” do modelo.

A exceção: repetir a cada evento

A opção “Repetir a cada evento recebido” (menu de contexto da caixa) transforma todas as entradas ligadas em portas “ou” não bloqueantes: a caixa volta a disparar a cada valor recebido, em qualquer porta.

Dois usos: tratar um fluxo mensagem a mensagem e desbloquear um ciclo de conclusão (um grafo que volta a si mesmo).

done contra uma saída de valor

É a distinção mais útil na prática:

• uma saída de valor emite assim que a caixa produziu o seu resultado;
• done espera, para além disso, que tudo o que consome esse resultado tenha terminado.

Para sequenciar — “faz tudo isto, depois limpa” — faça a ligação a partir de done. Para passar um dado, faça a ligação a partir da saída de valor.

Os ramos condicionais

Não são um mecanismo à parte: são portas de saída portadoras de um papel, que determina a sua cor.

Caixa	Saídas
If	then / else
While, Do…While	then (o corpo)
Assert	then (sucesso) / else (falha)
Retry	attempt / exhausted
Validação de esquema	valid / invalid / errors
Switch	uma porta por caso, mais default
Ligação Socket.IO	uma porta por evento declarado, mais others

Seletores de ligação

Uma ligação pode ter um seletor: um caminho aplicado ao valor em trânsito.

data.items[0].id
body['user-id']
headers["content-type"]
status

As formas a.b, a[0], a['clé'] e a["clé"] são aceites. Um segmento que contenha JSON é analisado ao passar; um caminho que não corresponda a nada dá undefined.

O Restorm por vezes deduz um seletor sozinho no momento da ligação, quando a origem tem uma pré-visualização estática que se reduz a um único valor primitivo. Pode sempre substituí-lo ou esvaziá-lo.