Skip to content

Custom options are accessible in serializer #512

Merged
merged 1 commit into from Aug 22, 2014

5 participants

@TimPetricola

Possible to access @options in a Serializer as it was in 0.8.

By doing so, you can use the options to filter attributes:

def filter(keys)
  keys.delete(:foo) if @options[:bar]
  keys
end
@joefiorini

:+1: I would like to see this as well. My use case:

I'm using CarrierWave and need to return image urls in my API. I'd like to have 1 serializer that renders an array of image urls. I was thinking of creating a declarative API for it like:

attribute :cover_image, serializer: ImageVersionSerializer, versions: [:thumb, :large]

But I can't specify versions without access to the options.

@ahx
ahx commented Mar 5, 2014

I have a similar use case where a serializer should render an array of things (time series elements) and i need to pass a time range parameter to the serializer.
I could not find a good solution for this without subclassing ActiveModel::Serializer and ActiveModel::ArraySerializer.
Having access to options would be really helpful. (+1)

@ahx
ahx commented Mar 5, 2014

Having a dedicated :context option for user defined options could be another option.
This way we would make sure that "reserved" options like meta, meta_key, root and scope don't cause conflicts.

@TimPetricola

@ahx I really like this approach. Done :wink:

@ahx
ahx commented Mar 10, 2014

Cool. Oat (https://github.com/ismasan/oat) is using this approach as well btw.

@timiyay
timiyay commented May 1, 2014

+1

@steveklabnik

I like this. Can I get a rebase, please?

@steveklabnik

Thanks! Let's see what Travis says...

@steveklabnik steveklabnik merged commit ae7959b into rails-api:master Aug 22, 2014

1 check passed

Details continuous-integration/travis-ci The Travis CI build passed
@steveklabnik

Travis says yes! thank you! :heart:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.