Add scenario to test coercion of grape entity

[keithpitty]

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.

[grape-bot]

	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

[keithpitty]

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.

[dblock]

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

[keithpitty]

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]

@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]

@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]

cc: @LeFnord for visibility

[LeFnord]

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]

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.