Avoid coercion of a value if it is valid

[timothysu]

This PR aims to simplify the logic (and expensiveness) of coercion by not coercing the param if it is already a valid value unless a custom coercer is provided, which resolves issues we're run into around JSON until further work can be done to improve the experience. Relates to #1685

[timothysu]

Let me take a look at failing specs - didn't encounter them locally...

[timothysu]

Ready for review

[dblock]

Just a few questions I am not sure about ...

[dblock]

Enumerable by definition has all?, how are we hitting a path where respond_to?(:all?) is needed?

[timothysu]

As I'm now checking for valid_type? before value is coerced, it means that value now could be anything. The Proc that's defined here is used in def success? on line 96, which has the annotation of # This method is called from somewhere within +Virtus::Attribute::value_coerced?+ in order to assert that the value has been coerced successfully. valid_type? directly calls value_coerced?, bringing this full circle. I think the confusion is around elsif type.is_a?(Enumerable), where type refers to the target/desired post-coercion type (eg. Array) rather than the type of value.

Without it, specs that go from '1 2 3' to [1, 2, 3] would fail as the type check on '1 2 3' would attempt to directly call '1 2 3'.all? ... which can't be done on a String.

[dblock]

Makes sense.

[dblock]

Can you explain respond_to?(:method) here?

Then, these seen unrelated, so to make it readable I would break it up.

return true if valid_type?(value)
return true if ...
false

[timothysu]

.method is defined if a custom coerce_with had been specified by the user, or the destination type has a defined coercion that everything needs to go through despite validity. I added a test that shows why this is needed, if that's the behavior we want (which is the current behavior, as everything is coerced once before type checking).

The conditionals are all directly related because of the following statements:

If the value is not valid, we require coercion.

Otherwise (if the value is valid), we require coercion it if a `method`  has been defined and it is not JSON.

which is written explicitly as:

def requires_coercion?(value)
  if !valid_type?(value)
    return true
  else
    if converter.coercer.respond_to?(:method) && !converter.is_a?(Grape::Validations::Types::Json)
      return true
    else
      return false
    end
  end
end

which could go to:

def requires_coercion?(value)
  return true if converter.coercer.respond_to?(:method) && !converter.is_a?(Grape::Validations::Types::Json)
  return true if !valid_type?(value)
  false
end

which condenses to the logic given. Is the one with explicit return trues still what is preferred?

[dblock]

I don't really care much, this is fine as is ;)

[dblock]

Merged, thank you.