The ask
Swap the activity leaf's parameter order to helpers first, input second — matching oRPC, which is the reference shape for this family.
// today
place: (args, { errors }) => …
// proposed
place: ({ errors }, args) => …Why
@btravstack/* ships three transports — HTTP over oRPC, Temporal over @temporal-contract/worker, AMQP over @amqp-contract/worker — and its flagship pitch is that the same use case moves between them: the same application module, the same ports, the same mapErrCases triage, a different runtime.
The mint and compose calls already share one shape across the three. The leaf function a developer actually writes does not, and it is the one thing they type by hand:
| Transport |
Leaf |
| HTTP (oRPC) |
place: ({ errors, context }, input) => … |
| Temporal (this library) |
place: (args, { errors }) => … |
AMQP (@amqp-contract) |
sync: ({ logger }) => ({ payload }) => … |
Someone moving a use case between transports relearns the leaf shape each time, for no reason either transport imposes.
oRPC is the reference because it is the most widely used of the three, not because its ordering is inherently better — a developer arriving at @temporal-contract has more likely seen oRPC than the reverse, so it is the shape that costs the least to match.
Why not fix it downstream
@btravstack/temporal-worker's TemporalWorkflowActivities owns the call site and could adapt the parameters. It should not: the leaf's type is inferred from this library's contract types, so an adapter would have to re-derive it — and it would leave the starter's documentation and this library's documentation describing the same function with two different signatures. Better to be one shape everywhere.
Cost
Breaking, and cheapest now: @temporal-contract v8 is still in beta, and the one consumer we know of (@btravstack/temporal-worker and its examples) is ours and moves in lockstep. After v8 goes stable it costs a deprecation cycle.
Filed from btravstack/btravstack#207.
The ask
Swap the activity leaf's parameter order to helpers first, input second — matching oRPC, which is the reference shape for this family.
Why
@btravstack/*ships three transports — HTTP over oRPC, Temporal over@temporal-contract/worker, AMQP over@amqp-contract/worker— and its flagship pitch is that the same use case moves between them: the same application module, the same ports, the samemapErrCasestriage, a different runtime.The mint and compose calls already share one shape across the three. The leaf function a developer actually writes does not, and it is the one thing they type by hand:
place: ({ errors, context }, input) => …place: (args, { errors }) => …@amqp-contract)sync: ({ logger }) => ({ payload }) => …Someone moving a use case between transports relearns the leaf shape each time, for no reason either transport imposes.
oRPC is the reference because it is the most widely used of the three, not because its ordering is inherently better — a developer arriving at
@temporal-contracthas more likely seen oRPC than the reverse, so it is the shape that costs the least to match.Why not fix it downstream
@btravstack/temporal-worker'sTemporalWorkflowActivitiesowns the call site and could adapt the parameters. It should not: the leaf's type is inferred from this library's contract types, so an adapter would have to re-derive it — and it would leave the starter's documentation and this library's documentation describing the same function with two different signatures. Better to be one shape everywhere.Cost
Breaking, and cheapest now:
@temporal-contractv8 is still in beta, and the one consumer we know of (@btravstack/temporal-workerand its examples) is ours and moves in lockstep. After v8 goes stable it costs a deprecation cycle.Filed from btravstack/btravstack#207.