Open kuraga opened 9 years ago
Do you have a real world scenario for something like this that you'd like to share?
Yes, and the code above contains it: 1) a car has many attributes, 2) when I create a car, I should receive some of them as parameters, 3) when I update a car, required parameters are else. And I don't want to code the list of parameters twice. Well it's just big, that's not DRY.
Yes, this makes sense. I wonder though whether the entire group should be made optional vs. required, so requires :car
instead of :use
. Another variation that seems like a more natural extension is to merge the params via use
with a block, instead of set ...
, I would definitely take a PR that accomplishes this:
use :car do
requires :name
optional :color
end
@dblock thank you for response!
Well use
way is just an example. I can (just) redefine mode later. See the (updated) second example in topic-start please.
Yep, I think overwriting parameters either way is a reasonable feature request. Maybe it already works? ;)
I went through some issues here and I saw a lot of them regarding parameters which led me to thinking about them a bit. Did you think about moving them to separate gem (some time ago you did it with entities - great work)?
However, it will be less in DSL style then. Quick example (could be totally different):
module API
module Parameters
class UserParams < Grape::Parameters
parameter :first_name, require: true,
parameter :last_name, require: -> (){}
parameter :address do
parameter :city, type: String, require: true
end
end
end
end
post '/user' satisfy: API::Parameters::UserParams do
end
btw. Is there any Gitter room for grape to discuss such things?
Yeah, OOP solution is a good idea! @dblock what do you think?
I don't have strong opinions, although I am always apprehensive about introducing new DSL language (eg. satisfy
). I would want to just be able to say params API::Parameters::UserParams
.
Has been a while :)
Is there any update on changing parameters to be required/optional later on? For us it's also a common use case when defining POST
& PATCH
endpoints. So far we just work around this with leaving the specific parameters out of the optional group and defining them explicitly via requires
and optional
, but I feel like such a mechanism would be more elegant...
Good day! I have a suggestion. The next code illustrates it:
UPD: Another example:
What's your opinion? Thanks.