The send / receive operations can be confusing because of their implicit / vs explicit nature. When you see a send operation or a receive operation, You have to track in your head which one is going to a different place, and which one is going to the implicit message queue for a given task.
This can be tricky if your eye doesn't catch a function boundary while scanning the code:
if (someCondition) {
// same mailbox as enclosing block.
yield receive();
}
vs
yield onEach(function*() {
// different mailbox from enclosing block.
yield receive();
});
Also, for those not familiar with the watch API, the implicit semantics can be tricky because it's unclear what "thing" the watch operation is changing, and where exactly messages are going to do.
// what exactly is this doing?
yield watch(connection, "message");
It's worth noting that from a purely resource perspective, we're creating a message queue for every single effection operation, most of which go completely unused, which seems like awaste.
As a little weekend project, I made this experiment with extracting the mailbox mechanism from an implicit effection operation to an explicit one that lives inside the @effection/events package as a natural "effection-savvy" mechanism for working with events.
The above examples are now unambiguous:
if (someCondition) {
// receive message from `mailbox`
yield mailbox.receive();
}
The send / receive operations can be confusing because of their implicit / vs explicit nature. When you see a
send
operation or areceive
operation, You have to track in your head which one is going to a different place, and which one is going to the implicit message queue for a given task.This can be tricky if your eye doesn't catch a function boundary while scanning the code:
vs
Also, for those not familiar with the
watch
API, the implicit semantics can be tricky because it's unclear what "thing" thewatch
operation is changing, and where exactly messages are going to do.It's worth noting that from a purely resource perspective, we're creating a message queue for every single effection operation, most of which go completely unused, which seems like awaste.
As a little weekend project, I made this experiment with extracting the mailbox mechanism from an implicit effection operation to an explicit one that lives inside the
@effection/events
package as a natural "effection-savvy" mechanism for working with events.The above examples are now unambiguous:
Oddly enough, doing it explicitly this way made the actual implementation much simpler than the implicit version.