Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Nested and listed predicates #498

wants to merge 3 commits into


None yet
4 participants

Looking ahead to the 0.9 update I realized I'd have to rewrite some monkey patches I'm using to keep a simple feature I've hacked into my serializers. I thought I'd take the opportunity of the alpha/refactor to see if perhaps they belong in AMS proper.

This pull request does not rebase cleanly into the refactor branch, something I can tend to if the general concept is vetted.

It allows virtual attribute and inclusion/filter methods to behave differently depending on the context a serializer is invoked in, nested? from ActiveModel::Serializer::Association and listed? from ActiveModel::ArraySerializer. For example:

class PostSerializer < ApplicaitonSerializer
  attribute :title, :body, :published_at
  has_one :author
  has_many :comments

  def include_author?
    not nested?

  def include_comments?
    not listed?

This will not display the author of the post if serialized in a nested context, for example as a serialized user's favorite_post. It will also not display the post's comments if serialized as a group of posts, for example as a user's publications. nested? and listed? should only both be true when serializing has_many associations.

Since my API gets more verbose the more you drill down on a resource, this keeps me from needing up to 4 different classes in combination to handle the possible permutations, and could be a useful pattern to incorporate into AMS (YMMV). It also will play very nicely with the centralized filter method in the upcoming release, since attributes in these contexts tend to be included/excluded in batches.

I just went looking to see if this had been implemented. I think the syntax would be quite useful (as opposed to having to maintain several serializer classes, as you mention).


steveklabnik commented Jul 28, 2014

I'm not sure that I want to change 0.9's DSL. We can talk about getting it into the 0.10, though, but the implementation would end up being different, so I'm going to give this a close.

I have a new project applying similar monkey patches to 0.9.0.alpha1 that adds these features successfully. Once 0.9.0 proper drops I'll restart the conversation on how and when to implement. It's entirely an extension to the existing DSL–no backwards incompatibilities–so I think it could comfortably ship with any given release.

Have you had any further thoughts on this? I can work towards a mergeable PR.


kurko commented Feb 1, 2015

@christhekeele can I suggest you open an issue with a proposal for the new DSL before going for a PR? We'd need to discuss how it'd work, its interface and API. Sounds good?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment