Skip to content

Fix reference creation when two types are provided #756

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

Merged

Conversation

bikolya
Copy link
Contributor

@bikolya bikolya commented Aug 28, 2019

Previously the type from param definition would be used to documentation even if we try to override it in the documentation hash.
It caused Swagger UI to render, for example, "Unknown Type: Color" instead of using the provided entity.

It terms of code, before this change we would return something like this:
{ color: { type: 'Color' }
instead of:
{ color: { '$ref' => 'ColorEntity' }
if Color is not inherited from Grape::Entity

Having different types can be useful when two different classes are used for parsing and presenting an attribute.
E.g. the input format for Base64 File can be represented as a Hash (content, content_type and filename), whereas the type after parsing can be ActionDispatch::Http::UploadedFile.

In the current situation the solution to this problem is to put coercion methods to the same entity and specify type only for the param without using documentation.

@coveralls
Copy link

coveralls commented Aug 28, 2019

Coverage Status

Coverage remained the same at 99.33% when pulling 75e3b31 on bikolya:fix-ref-creation-when-two-types-provided into 445d2d4 on ruby-grape:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 99.33% when pulling cea406d on bikolya:fix-ref-creation-when-two-types-provided into 445d2d4 on ruby-grape:master.

Previously the type from param definition would be used to documentation
even if we try to override it in the `documentation` hash.
It caused Swagger UI to render, for example, "Unknown Type: Color"
instead of using the provided entity.

It terms of code, before this change we would return something like this:
{ color: { type: 'Color' }
instead of:
{ color: { '$ref' => 'ColorEntity' }
if Color is not inherited from Grape::Entity

Having different types can be useful when two different classes
are used for parsing and presenting an attribute.
E.g. the input format for Base64 File can be represented as a Hash (content,
content_type and filename), whereas the type after parsing can be
ActionDispatch::Http::UploadedFile.

In the current situation the solution to this problem is to put coercion
methods to the same entity and specify `type` only for the param without
using `documentation`.
@bikolya bikolya force-pushed the fix-ref-creation-when-two-types-provided branch from cea406d to 75e3b31 Compare August 28, 2019 14:44
@LeFnord
Copy link
Member

LeFnord commented Sep 5, 2019

thanks @bikolya

@LeFnord LeFnord merged commit 204ced4 into ruby-grape:master Sep 5, 2019
aka-momo pushed a commit to aka-momo/grape-swagger that referenced this pull request Feb 8, 2023
Previously the type from param definition would be used to documentation
even if we try to override it in the `documentation` hash.
It caused Swagger UI to render, for example, "Unknown Type: Color"
instead of using the provided entity.

It terms of code, before this change we would return something like this:
{ color: { type: 'Color' }
instead of:
{ color: { '$ref' => 'ColorEntity' }
if Color is not inherited from Grape::Entity

Having different types can be useful when two different classes
are used for parsing and presenting an attribute.
E.g. the input format for Base64 File can be represented as a Hash (content,
content_type and filename), whereas the type after parsing can be
ActionDispatch::Http::UploadedFile.

In the current situation the solution to this problem is to put coercion
methods to the same entity and specify `type` only for the param without
using `documentation`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants