-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define contract instead of params #2386
Comments
It's a good idea. It could just be an extension to |
Hi folks! I've done a little write-up on ways to use dry-validation and grape together. Here's the repo with the example. Note that this approach adds a new helper to be used instead of A deeper integration seems more difficult. Also note that dry-schema doesn't support renaming/aliasing, so it's not a full superset in terms of features (though processor callbacks seem to fit as a workaround). |
I love the idea of |
If we likewise dispatch Dispatching contract do
params do
...
end
rule(:abc) { ... }
...
end If the first call in the above snippet is renamed to |
We should put the implementation aside for a second, and only talk DSL and user-facing behavior, it will make things easier. On your comments specifically.
Yes, I think that
Why not? I think users would appreciate if contracts were to enforce the same behavior you'd expect from any parameter validation and coercion layer.
If validation fails (contract not satisfied), you should get a validation error back on the client just like with Regarding the use of Another thought. I am confused seeing contract do
params do
filled(OrderSchema)
end
rule do
next if value[:baskets].count < 10
key.failure('contains too many baskets')
end
post do
order = Order.create!(declared(params))
end Finally, on nesting/not nesting in |
Sure. The question is whether they'd have to give something up as well, in performance or capabilities.
That definitely makes sense.
I was trying to remember when was it that I found it useful to have a different value in resource :bars do
route_param :bar_id do
resource :foos do
params do
...
end
post do
puts declared(params)
end
end
end
end where Anyway, the case of including the parent scopes' parameters in the declared set needs to be handled. My current implementation would filter them out, as long as they are not mentioned in the endpoint's schema directly.
And
In that example contract do
params do
required(:baskets).array(BasketSchema)
end
rule(:baskets) ... or the schema can be assigned this way: contract do
params(OrderSchema) # This actually creates a new schema inheriting from this one.
rule(:baskets) ...
end
The point in having FWIW, I'm not sure if rules really have to be supported with the inline syntax -- it could just support defining a schema. But it would accept being passed an existing contract class that contains both schema and rules (and maybe macros). |
Good discussion and everything you said makes a lot of sense! Want to try a PR that introduces basic functionality that lets one switch between existing |
Sure, I'll give it a shot. |
Resolves ruby-grape#2386
And add a test for that. ruby-grape#2386
And add a test for that. ruby-grape#2386
Hey 👋
Sometimes, we can have a huge amount of params to be received in an endpoint. To define all those parameters in the params section can make the received params difficult to read. Additionally, managing custom validations and error messages specific to these parameters becomes challenging.
Due to this, I've seen several implementations where they use dry-validations contract instead of the
Grape
params.Would be great to provide this feature directly by
Grape
like:I can see that we are already using
dry-types
for validatingparams
(#1347 ).The text was updated successfully, but these errors were encountered: