Optionally coerce all params even if one fails. #363
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds a `:reitit.coercion/coerce-all-on-error?` option that
ensures that all parts of requests are coerced even if one fails.
Previously, only the first coercion failure would be returned.
Since the current coercion exception ex-data format can't really be
used to accomodate multiple errors, this format changes from:
`{ "in": [ "request", "path-params" ], "errors": ... }`
..to:
`{ "path-params": { "errors": ... }, "body": { "errors": ... } ...}`
when `:coerce-all-on-error?` has been set.
It probably makes sense to switch to the new format even when
`coerce-all-on-error?` is disabled, as well as and enable
`coerce-all-on-error?` by default at some point. However, it's probably
best to hold off on this until 1.0.0, since the format change means it
would break backwards compatability for downstream middleware and
interceptors.
I also made sure that response coercion behaves the same way as request
coercion wrt the new option, even though there's only one supported
response coercion type (body) currently.
I also added a missing `:` in the `::keys` option destructuring in
`response-coercer` (previously, users would have had to set
`:reitit.coercion/extract-request-format` for requests but
`:extract-response-format` for responses).
aeriksson
commented
Feb 9, 2020
| (update :coercion -get-name) | ||
| (->> (-encode-error (:coercion data))))) | ||
| (if (not-any? #(contains? data %) | ||
| [:body :form-params :query-params :headers :path-params]) |
There was a problem hiding this comment.
This might not be the cleanest way to tell the old and new format apart. Perhaps it'd been better to handle this by adding an additional key to the ex-info data?
|
Note: the tests seem to be failing on master, so I haven't actually run them on this branch. I can do a rebase, fix and force-push whenever master is working again. |
aeriksson
commented
Feb 11, 2020
| @@ -53,7 +55,27 @@ | |||
| :in [:request in] | |||
| :request request})))) | |||
|
|
|||
| (defn ^:no-doc response-coercion-failed! [result coercion value request response] | |||
| (defn ^:no-doc merge-coercion-errors | |||
| "Coalesces a list of coercion errors on the form `{:in <>}`" | |||
There was a problem hiding this comment.
Reminder to self: fix this docstring.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR targets issue #362.
This commit adds a
:reitit.coercion/coerce-all-on-error?option thatensures that all parts of requests are coerced even if one fails.
Previously, only the first coercion failure would be returned.
Since the current coercion exception ex-data format can't really be
used to accomodate multiple errors, this format changes from:
{ "in": [ "request", "path-params" ], "errors": ... }..to:
{ "path-params": { "errors": ... }, "body": { "errors": ... } ...}when
:coerce-all-on-error?has been set.It probably makes sense to switch to the new format even when
coerce-all-on-error?is disabled, as well as and enablecoerce-all-on-error?by default at some point. However, it's probablybest to hold off on this until 1.0.0, since the format change means it
would break backwards compatability for downstream middleware and
interceptors.
I also made sure that response coercion behaves the same way as request
coercion wrt the new option, even though there's only one supported
response coercion type (body) currently.
I also added a missing
:in the::keysoption destructuring inresponse-coercer(previously, users would have had to set:reitit.coercion/extract-request-formatfor requests but:extract-response-formatfor responses).