*** NoMethodError Exception: undefined method for empty field

[scott-silver]

I have a Contentful model (blogAuthor) that has an optional text field (bio).

If an author has a value for bio, the Contentful::Entry for that author will have a bio method, and it will return the value when called.

But if there is no bio, then the Contentful::Entry throws and error when you access the bio method:

author.bio
*** NoMethodError Exception: undefined method `bio' for <Contentful::Entry[blogAuthor] id='...'>:Contentful::Entry

nil

From the docs, it looks like the solution to this issue is to set dynamic_entries: :auto, but enabling this option doesn't seem to change the type of Contentful::Entry to Contentful::DynamicEntry (looks like Dynamic Entry has possibly been removed?)

@dlitvakb In version 2x of the gem, what is the correct way to access an optional field on Contentful::Entry that won't result in a NoMethodError if the value is nil?

[dlitvakb]

Hey @scott-silver,

DynamicEntry has been replaced with a Content Type Cache instead and it's used for field type coercion.

I'm currently implementing a solution for your issue, that's going to be included in the next minor release, which I'm doing later today.

The solution will be the following:

By default, trying to access a field of an entry with an undefined value (the field is not sent back from the API), it will raise an EmptyFieldError exception with the message "The field '#{field_name}' is empty and unavailable in the response", which you can capture and do something about.

Or, if you send raise_for_empty_fields: false on client creation, it will return nil.

If you try to access an unknown method on the entry and the content type doesn't have any matching field, it will return a NoMethodError. Also, if dynamic_entries: :manual it will also return NoMethodError, as the content type cache will be empty.

The default behaviour will be to raise an exception due to the fact that right now it's already raising an exception, and not raising an exception is a breaking change, we're just changing the kind of exception raised.

Hope this will solve you issue,

Cheers

PS: For the moment, to solve your issue without the need for update, you can do: either entry.respond_to?(:bio) or entry.fields.key?(:bio), this will let you know if the method is available or not.

[dlitvakb]

This has just been released.

Cheers

[scott-silver]

that's awesome, thanks @dlitvakb!

[AfolabiOlaoluwa]

PS: For the moment, to solve your issue without the need for update, you can do: either entry.respond_to?(:bio) or entry.fields.key?(:bio), this will let you know if the method is available or not.

Thanks.

But if I want to wrap all the methods in one argument, is that possible? Such that I can have something like entry.fields.key?(:bio, :name, :title, :description), then I can throw my solution into just one if..else

[AfolabiOlaoluwa]

So I tried it, I figured out it only accepts one argument. Here is the error I go wrong number of arguments (given 2, expected 1)

[thisismydesign]

Ran into this issue regardless of the fix. Turns out, fields that are disabled in the response are not covered by raise_for_empty_fields. It would be nice to have an option to gracefully handle this case. Otherwise a contentful config change can break the app.