Review finding 12/19 · conventional-comment question (API arbitration) · area binder · gate: decide before the v1 API freeze
To add once they exist: label binder; milestone v1. (Already applied: question.)
Problem
The README describes binding a request "body + route", and the predecessor (fluent-request-binder) had Bind.Arguments() for values that do not come from the DTO body (route / query values). The current API binds only DTO properties — there is no way to bind an out-of-DTO argument.
Impact
A consumer whose command needs a route or query value (for example an id from the path) cannot express it through the binder, so either the README over-promises or the API is incomplete for the stated use case.
Decision needed
Choose one, before the v1 freeze.
Options
- Add an additive
bind.Argument(name, value) (and/or a route/query source) so out-of-DTO values participate in the same collect-all envelope with proper paths.
- Correct the README to state that the binder binds the DTO only, and document how a caller folds route / query values in.
Context
Surfaced by the RequestBinder review (design spec #126, shipped in #141). Finding 12 of 19 — the one flagged as needing an API decision.
Problem
The README describes binding a request "body + route", and the predecessor (fluent-request-binder) had
Bind.Arguments()for values that do not come from the DTO body (route / query values). The current API binds only DTO properties — there is no way to bind an out-of-DTO argument.Impact
A consumer whose command needs a route or query value (for example an
idfrom the path) cannot express it through the binder, so either the README over-promises or the API is incomplete for the stated use case.Decision needed
Choose one, before the v1 freeze.
Options
bind.Argument(name, value)(and/or a route/query source) so out-of-DTO values participate in the same collect-all envelope with proper paths.Context
Surfaced by the RequestBinder review (design spec #126, shipped in #141). Finding 12 of 19 — the one flagged as needing an API decision.