Optional attributes / Passing arbitrary params to serializer

[kenn]

(from #552) I just realized that AMS is in flux. But I'd throw in my issue (based on 0.9), anyway.

We have a master-detail view where the master shows a list of conversations with the last message included, and the detail displays one conversation with all messages.

One way to do it is:

class Conversation
  has_many :messages
  has_one :last_message
  attr_accessor :show_details
end

class ConversationSerializer < ActiveModel::Serializer
  attributes :last_message, :messages

  def attributes
    if object.show_details
      super.except(:last_message)
    else
      super.except(:messages)
    end
  end
end

# controller
@conversation.show_details = true
render json: @conversation

But this feels wrong on two fronts:

• The model shouldn't contain view (or serializer, in this case) concerns like show_details. There should be a way to directly pass the hint from controller to serializer, not through model.
• It doesn't work when it's called from an array context - you need to do conversations.each{|i| i.show_details = true }. The hint should be stored at the array level, not at the item level.

For those reason, I would suggest that we enable to pass arbitrary parameters to the serializer, from controller.

class ConversationSerializer < ActiveModel::Serializer
  params :show_details

  def attributes
    if @show_details
      super.except(:last_message)
    else
      super.except(:messages)
    end
  end
end

# controller
render json: @conversation, serializer_params: { show_details: true }

and pass down the params to each item, when the target was an array.

That way, we don't have to alter the model and separation can be done nicely. What do you think?

[kenn]

This feature will ensure more flexibility - like pagination in embedded objects.

class ConversationSerializer < ActiveModel::Serializer
  params :show_details, :page, :per_page

  def attributes
    if @show_details
      super.merge(messages: object.messages.page(@page).per(@per_page))
    else
      super.merge(last_message: object.last_message)
    end
  end
end

# controller
render json: @conversation, serializer_params: { show_details: true, page: params[:page], per_page: params[:per_page] }

[tchak]

in case of full/detail view I would suggest using two serializers with a common shared parent if needed and then do :

render json: @conversation, serializer: ConversationDetailSerializer

Do you have any other use cases?

[kenn]

@tchak I don't like that approach (as mentioned in #552), because it requires at least 3 classes to achieve DRY-ness just to handle one optional attribute. It quickly gets out of control when you have more optional behaviors.

Let's assume that you have a user class, which has limited accessibility for the public profile, and expose more data for your friends. The class also has "following" and "followed" flag, which represents relationship, but those relationship attirbutes won't be included if it was called from yourself, or you're not logged in. When it's called from yourself, the class includes "email_confirmed", to display alert if the email hasn't been confirmed yet.

class UserSerializer < ActiveModel::Serializer
  attributes :id, :username, :created_at, ...

  params :authorization, :include_details

  def attributes
    base_attributes = @include_details ? super.merge(details: object.details) : super

    case @authorization
    when :public
      base_attributes
    when :myself
      base_attributes.merge(email_confirmed: object.email_confirmed?)
    when :loggedin
      base_attributes.merge(following: scope.following?(object), followed: scope.followed?(object))
    when :friends
      base_attributes.merge(following: scope.following?(object), followed: scope.followed?(object), friends_only_data: object.friends_only_data)
    end
  end
end

# controller
render json: @user, serializer_params: { include_details: true, authorization: :friends }

With this fairly simple example, you already need 9 classes if you go with the inheritance way. We need a way to manage combinatorial explosion.

[kenn]

Yet another example, a picture model using paperclip, that automatically choose the best thumbnail for a given numeric size.

class Picture < ActiveRecord::Base
  has_attached_file :data, { tiny: '32x32^', small: '48x48^', ... }
end

class PictureSerializer < ActiveModel::Serializer
  attributes :url, :content_type
  params :size

  def url
    object.data.url(thumbnail_key)
  end

  def thumbnail_key
    case @size
    when 0..32
      :tiny
    when 33..48
      :small
    ...
    else
      :original
    end
  end
end

# controller
render json: @pictures, serializer_params: { size: 100 }

One nice thing about this design is that controller's params can be handled by strong_parameters or rails_param, then mass-assigned.

render json: @pictures, serializer_params: params.permit(:size)

[kenn]

Another way of doing it might be accepting a serializer instance rather than a class:

render json: @pictures, serializer: PictureSerializer.new(params.permit(:size))

[dilizarov]

Just noticed this, and think this addition is needed for flexibility. I love this gem, but it would be helpful to easily bring in data that is indirectly related to the model. For example, imagine showing a user a list of his or her clubs, and showing the number of users in each club. It is easy to get the number of users for each club like such: UserClub.group_by(:club_id).count(:user_id), but then if you want to serialize a Club with the attribute :number_of_users, it isn't easy.

The following is a solution, but would lead to N + 1 Queries. Ultimately, one would like to be able to pass in the value from the outside.

class ClubSerializer < ActiveModel::Serializer
  attributes :name, :creator_id, :number_of_users

  def number_of_users
    UserClub.group_by(:club_id).count(:user_id)[object.id]
  end
end

Also, one could include this information in the meta of the JSON, but that doesn't feel right either.

[jbhatab]

I have a scenario where I need params as well. I need to get the amount of weight a user lost based on a date range. I can't think of any other way to do this without passing in params.

[dilizarov]

@jbhatab, I found a solution, which I feel is a tad hacky, but works.

If you reference my post, right above yours, you see that I need the number_of_users per club. One way to do it is the following:

class Club < ActiveRecord::Base
  attr_accessor :number_of_users

  #Whatever else you would have in your model
end

Then, before you try to serialize it, you would take your object, club, and simply give it the value it needs based on calculations you did elsewhere. So, you'd do something like club.number_of_users = 59.

Once you have that, in your serializer, do something like:

class ClubSerializer < ActiveModel::Serializer
  attributes :name, :creator_id

  def attributes
    data = super
    data[:number_of_users] = object.number_of_users unless object.number_of_users.nil?
    data
  end
end

[kenn]

@dilizarov @jbhatab It is demonstrated in my original post. 😄 Still, we need a way to separate view concern / serializer concern from models.

[dilizarov]

@kenn Oh, I didn't notice that you already showed that method. I think we're all in agreement though. Params would be awesome.

[jbhatab]

@dilizarov @kenn Thanks for the temp fix. The documentation on this issue is all over the place. The github has closed issues that seem like it fixed it, open issues that say it's a problem, and stack overflow posts that say it's answered but it's not. Just letting you guys know.

What is the guy in this post referencing? Isn't this "params"? Because it doesn't work.

http://stackoverflow.com/questions/23347587/how-to-pass-parameters-to-activemodel-serializer

[jbhatab]

Also can't I just do the following if I'm using attr_accessor instead of the attributes super thing.

attributes :number_of_users

That should get the correct value and put it in the serialized data correctly.

[kenn]

Looks like a patch has been merged to master. #679 I would prefer something shorter than serialization_options[:show_details], though.

I'll try to cook up a pull request if we like params macro and ivar assignment better as shown in my comments above. WDYT? @steveklabnik

[dilizarov]

@jbhatab Sure, but for API requests that don't need the number_of_users, you'll have the :number_of_users attribute be nil for every club. My method opts out of that.