-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
If my understanding is correct, when processing a request through grape, the request appears to be proxied using an anonymous instance of Grape::Endpoint, which breaks common assumptions of class inheritance.
For example:
class B < A
get :action do
should_inherit # throws: NoMethodError (undefined method 'should_inherit' for <#<Class:0x...>:0x...>)
end
end
class A < Grape::API
def should_inherit
"This should be available in class B when handling a request."
end
endWhen called from outside of the context of a grape API request, should_inherit resolves as expected. But when handling a request, a NoMethodError is thrown as the superclasses are not reflected in the ancestry chain of the anonymous Grape::Endpoint instance that is created to serve the request.
This presents an obvious "gotcha" when attempting to create a base class that all endpoints extend from without actually modifying the Grape::API class itself. I know it's possible to work around this issue by using modules and "helpers", but doing so is prohibitively verbose and violates the DRY principle when having to include them in every single endpoint.
If possible, could grape be modified to follow normal class inheritance when serving requests?