Porter configuration, containing:

• ports
• message encoders/decoders.
• the message that porter will use for its internal communications

Porter model, used to keep track of response handlers.

Module messages.

Initialize model

Update port model based on local messages. Returns a new port model and a local command that must be mapped to the parent message.

Subscribe to messages from ports.

Turns the request's specialized response type into a different type.

Chains two requests, and then combines their two responses into one new c.

Chains three requests, and then combines their three responses into one new c.

Combines together multiple Porter.Multi requests

Opaque type for porter requests, where we can either:

• perform a single request, which will run the Porter Request and at the end turn the result into an outputRes. See request.
• perform multiple requests: At the end of this request, run a function on the output that generates the next request. Note that this is set up in such a way that only the type of the final request in the chain matters. See andThen.
• short-circuit: just pass on the value outputRes without doing any more requests. See succeed.

Creates a new request, specifying:

• the request itself in the common req type
• a response handler function tha turns the common res type into a specialized a.

A simpler version of request where the end result is not converted into a specialized type, but left the same.

Succeed with an outputRes value without making an actual request. This is especially useful inside andThen, where the request chain may need to shortcircuit because of the return value (e.g. should not update a record that hasn't been found).

Actually sends a (chain of) request(s).

A final handler needs to be specified that turns the final result into a msg. This msg will be called with the final resulting a once the final response has returned.