Skip to content
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

Add scenario to test coercion of grape entity #2036

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

keithpitty
Copy link

@keithpitty keithpitty commented Apr 3, 2020

This is a first attempt at exposing a regression in Grape 1.3.1 compared with 1.2.4 with respect to specifying subclasses of Grape::Entity as parameters.

My investigation so far has revealed that there is no provision within Grape::Validations::Types to handle subclasses of Grape::Entity. Presumably a new Grape::Validations::Types::GrapeEntityCoercer class needs to be created. This would be instantiated within Grape::Validations::Types::create_coercer_instance.

This is a first attempt at exposing a regression in Grape 1.3.1 compared
with 1.2.4 with respect to specifying subclasses of Grape::Entity as
parameters.
@grape-bot
Copy link

grape-bot commented Apr 3, 2020

1 Warning
⚠️ Unless you’re refactoring existing code, please update CHANGELOG.md.

Here's an example of a CHANGELOG.md entry:

* [#2036](https://github.com/ruby-grape/grape/pull/2036): Add scenario to test coercion of grape entity - [@keithpitty](https://github.com/keithpitty).

Generated by 🚫 danger

The addition of a GrapeEntityCoercer to handle subclasses of
Grape::Entity enables grape entity parameters to be specified without
resulting in the coercing logic to mark them as invalid.
@keithpitty
Copy link
Author

Note: This is still a work in progress. Whilst I've enabled a basic test case for a Grape::Entity to work, there are at least two more test cases I need to add.

Keith Pitty added 2 commits April 6, 2020 16:24
A grape entity can expose an attribute with a different key. So we need
to handle that case as well.
Validation of grape entities now handles an array. However, we still
need to ensure that the coerced values are returned.
@dblock
Copy link
Member

dblock commented Apr 6, 2020

I wonder whether GrapeEntityCoercer belongs in grape-entity. And if there's anything we can move out there from here further?

@keithpitty
Copy link
Author

I wonder whether GrapeEntityCoercer belongs in grape-entity. And if there's anything we can move out there from here further?

@dblock good question. I guess it prompts me to ask whether coercing an object which is an instance of a subclass of Grape::Entity is something that grape is intended to handle. If not, perhaps I should change my client code to not expect grape entities to be handled as params.

Given you're more familiar with the grape codebase than me, I'd be interested to hear more of your thoughts about this.

@dnesteryuk
Copy link
Member

@keithpitty @dblock I would pretend that Grape::Entity is a custom type which implements the parse method, thus, Grape won't know anything about Grape entity. I guess it is a right way to go, Grape shouldn't depend on Grape entity.

@dblock
Copy link
Member

dblock commented Apr 7, 2020

@keithpitty @dblock I would pretend that Grape::Entity is a custom type which implements the parse method, thus, Grape won't know anything about Grape entity. I guess it is a right way to go, Grape shouldn't depend on Grape entity.

I am saying the same thing. Grape does not depend on grape-entity, but handles grape-entity when it's loaded as needed for rendering. Grape-entity depends on Grape and should be introducing a parser that gets automatically registered when grape-entity is loaded.

I think the right thing to do would be to see a dependency on grape-entity removed from specs, entity specs moved into an integration test that loads grape-entity, and ensure both parsing and rendering work. Thoughts?

@dblock
Copy link
Member

dblock commented Apr 7, 2020

cc: @LeFnord for visibility

@LeFnord
Copy link
Member

LeFnord commented Apr 16, 2020

Hi …

wondering a bit about the approach, for my understanding the usage of Entities for params, should only avoid duplication

mean, from the Entity the stuff from the documentation key should be used for params, so I would expect by using it, a kind of copy over from the Entity to the parameter, and let do grape the rest a usual

expecting this copy over is implemented in grape-entity

@dblock
Copy link
Member

dblock commented Apr 16, 2020

Grape uses dry-types but is not too opinionated about coercion otherwise - what I am saying is that we're not trying to force everyone to convert a spec (eg. grape-entity) into Grape's way of checking parameters (dry-types), therefore introducing a concept of custom coercion. So while you certainly can copy-over, I don't think you have to. Either approach works.

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.

5 participants