Can not filter attributes dymically?

[groe]

In version 0.8.x it was possible to dynamically exclude certain attributes by implementing include_<name>? and returning false. In 0.9.x the same could be achieved with the filter(keys) method. For 0.10.0.rc3 this SO answer suggests overwriting the attributes method but that requires the attribute to exist anyway (and it is fetched always, even when excluded, which is not ideal from a performance point of view).

What is the recommended way to filter attributes (e.g. based on the current user, or options passed from the view) in 0.10.0.rc3 using the standard attributes adapter?

[bf4]

HI @groe would you mind giving an example of what you're trying to do so we can tailor our answer to your use case?

Pseudo-code is fine

[groe]

Hi @bf4, sure! One example would be to exclude attributes the current_user does not have access to.

Could be something like this:

class PostSerializer < ActiveModel::Serializer
  attributes :id, :name
  attributes :secret_token, :average_score, :if => :admin?

  def average_score
    # time consuming operation, which should only be executed if really needed
    object.scores.joins(...).average("SQRT(score * weight)")
  end

  def admin?
    scope.admin
  end
end

Or to exclude things which are not required, depending on the given params in the HTTP request:

class PostsController < ApplicationController
  def index
    @posts = Post.all
    render json: @posts, extra_columns: params[:extra_columns].split(",")
  end
end

class PostSerializer < ActiveModel::Serializer
  attributes :id
  attributes :name, :if => Proc.new { options[:extra_columns].include?("name") }
  attributes :content, :if => Proc.new { options[:extra_columns].include?("content") }
end

And another example would be to depend on the object itself:

class PostSerializer < ActiveModel::Serializer
  attributes :id, :name
  attributes :url, :if => :published?

  def published?
    object.published_at.present?
  end
end

In my current app the JSON in fact would depend on all of these: current_user (which is scope in AMS), params (which is options in AMS), as well as the object itself.

The DSL using :if is just a suggestion but I think it would be pretty idiomatic.

Let me know if I can help! Would be great to see this feature in 0.10.0 again!

[beauby]

I would tend to think those are actually controller concerns and that your situation should be resolved by chosing an appropriate serializer within the controller (although I understand this would amount to more code on your end).

[groe]

@beauby For simple examples, as above, that might work but the problem is that in my application there are numerous possible combinations of columns and privileges, which effect which columns are included in the JSON. If I would create 1 serializer class for each of these combinations that would be hundreds or thousands of classes required.

Or am I missing an other way to do it other than creating a serializer class for each combination of columns?

[beauby]

You are right, that was the direction I was hinting. The idea of a 0.8 style filter feature is currently being discussed, so feel free to advocate for it here :)

[bf4]

So, I think you can do what you want with the current code, but it's not well-documented (if this works, a PR would be great!)

Try using serialization_scope (tests)?

class AdminUserSerializer < ActiveModel::Serializer
  attributes :admin?
  def admin?
    current_admin.admin
  end
end
class SomeController < ActionController::Base
  serialization_scope :current_admin # default is :current_user
  def current_admin
    User.new(id: 2, name: 'Bob', admin: true)
  end
  def render_new_user
    render json: User.new(id: 1, name: 'Pete', admin: false), serializer: AdminUserSerializer, adapter: :json_api
  end
end
# get :render_new_user`
# => {"data":{"id":"1","type":"users","attributes":{"admin?":true}}}'
# where 'admin?' is the value of `current_admin.admin`

[beauby]

If you want to actually exclude some attributes from the response, you could use the technique @bf4 outlined in order to give those attributes a special value like :_do_not_serialize, and then override your serializer's attributes method as follows:

class PostSerializer < ActiveModel::Serializer
  ...
  def attributes
    attrs = super.delete(:_do_not_serialize)
    attrs
  end
end

[beauby]

Moreover, including attributes depending on a param is doable via the fields option.

[groe]

@bf4 I am not sure how this code solves the issue of including/excluding attributes dynamically?

@beauby Assigning :_do_not_serialize or alike has these problems:

1. Assigning it as a value for the attributes will not work with your code since it removes the key :do_not_serialize. So it would have to remove the attribute based on the value, not the key. That, however, would (besides that fact that iterating and comparing all attributes is bad performance-wise) introduce new problems since ActiveModel (or is it ActiveRecord?) would cast the value to the database column type and the serializer would have to check for that type.
2. It might also be possible to introduce an entirely new attribute named _do_not_serialize which is an array of columns to exclude. The problem with that is that the values are always fetched, even when the overriden attributes method removes them afterwards. For simple columns that hardly matters but for calculated values (see my example above), it would have a significant impact on performance. Also, it would require the model to always have this column.
3. It feels hacky (imo).

Thanks for the hint to the fields option but apparantly it removes all columns not listed in the array, so it would require developers to specify them always in the controller (or wherever they render JSON). I would think that knowing which columns to include/exclude based on the model, the user and the render context is a core responsibility of AMS, not the controller and any other place which requires JSON.

---

To give you some context: I am currently using jbuilder in my application to render JSON but my main reason to give AMS a try was that it allows to encapsulate JSON generation logic in a way that can be used anywhere in the application, not just in a controller action.

I tried 0.9.x before realising that it's a dead-end, then switched back to 0.8.x, which was missing other things I needed. In both 0.8.x and 0.9.x dynamically including/excluding is one of the first features mentioned in the README of the project. I thought that's a very good abstraction, which can be reused in lots of places (e.g. views, background workers or models when communicating with external APIs or message queues).

Now I am on 0.10.x and I am a little surprised that the feature seems to be gone now? Was it a deliberate decision to remove it? If so, why?

Is there a conceptual reason to not allow developers to specify :if and :unless options to the attributes method, similar to the ActiveRecord validations DSL?

[bf4]

Is there a conceptual reason to not allow developers to specify :if and :unless options to the attributes method, similar to the ActiveRecord validations DSL?

There's certainly a code reason, which I can go into, but, before we go down that road, are you certain you need those attribute options, or would you consider other ways to filter options?

I am not sure how this code solves the issue of including/excluding attributes dynamically?

given the desired code above

  attributes :secret_token, :average_score, :if => :admin?
  def average_score
    # time consuming operation, which should only be executed if really needed
    object.scores.joins(...).average("SQRT(score * weight)")
  end

  def admin?
    scope.admin
  end

you could implement this as

  serialization_scope :current_user
  attributes :secret_token, :average_score
  def average_score
    # time consuming operation, which should only be executed if really needed
    object.scores.joins(...).average("SQRT(score * weight)")
  end

  def

  def admin?
    current_user.admin
  end

  def attributes
    super do |attrs|
      return unless admin?
      attrs.delete(:secret_token)
      attrs.delete(:average_score) 
     end
  end

Alternatively, just have two serializers that you toggle in the controller based on the scope there

We want to make this easier, too, but we're just people like you, so PR's appreciated :)

[groe]

@bf4 I'm just advocating ;)
Great to hear that you want to make it easier too. I think this is relevant for lots of applications out there!

Having 1 serializer for each scope only works for a very limited number of potential attribute combinations (see above) and shifts the responsibility of deciding which attributes to include back to the controller and other places calling AMS. I would prefer to keep that logic centralized in the serializer instead.

Just to understand you correctly: Right now it's not possible to pass a block to attributes, is it? So you are suggesting this as an alternative (which would be easier to implement than the :if and :unless options?)

super do |attrs|
  return unless admin?
  attrs.delete(:secret_token)
  attrs.delete(:average_score) 
end

(I think you meant return if admin?, instead of return unless admin?)
Would that calculate the average_score only if necessary?