add if/unless options to attribute

[LcpMarvel]

No description provided.

[bf4]

I don't think we should support any options for attributes. That's always just a list. We use attribute for an attribute with options

[LcpMarvel]

You want to use

attribute :id, if: :admin?
attribute :titile, if: :admin?

instead of attributes :id, :title, if: :admin? ?

[beauby]

@bf4 I'm not sure I understand why we would not want to support options for attributes. Could you elaborate?

[bf4]

value to end-user is minimal, cost to library is relatively high

[beauby]

I would usually agree, but since we already support variable number of arguments and array of symbols as parameters to attributes, I don't believe the added cost is that high.

[bf4]

Thanks for this. This is a great feature! And has tests!

I personally don't think this is a good thing for AMS to support right now. I also don't think the overhead of supporting in on attributes is worth it right now. I'd be more in favor of a less invasive implementation that used a sentinel value to determine if an attributes should be excluded or a whitelist is being used., e.g. something like

attributes :banana, :tofu, :burger
def banana
  object.banana || ExcludedAttribute # can't use nil since that's a valid value
  # or 
  object.banana || ExcludedAttribute.new(:banana) # can't use nil since that's a valid value
  # or
  object.banana || :excluded_attribute
  # or 
  condition ? object.banana : :excluded_attribute
end

def tofu
  condition ? object.tofu : WhitelistedAttribute.new(object.tofu) # dunno, just thinking here
end

such that the if banana is ExcludedAttribute, attribute keys will be tofu and burger. If tofu is WhitelistedAttribute, then only tofu is a WhitelistedAttribute, then only other whitelisted attribute keys are used, so only tofu will be in the attributes. That way the feature just requires a value-check in the attributes method and the condition logic is easy to use, and maybe could lead to the suggested interface.

Also, I prefer only/except like Rails uses for this sort of thing

[beauby]

Although I am currently not convinced which way is better, it seems lots of people are expecting a feature similar to this one.
@bf4, out of curiosity, how would you see an only / except system work in this case?

[bf4]

@beauby you're right about only/except. I must have been thinking of something else, like fields which is a similar feature, params-driving, and is filtering only

[danhper]

Would this work for associations as well? For example:

has_one :profile, if: :admin?

I think it would be more consistent to support both with the same syntax.

You want to use

attribute :id, if: :admin?
attribute :titile, if: :admin?

instead of attributes :id, :title, if: :admin? ?

%i(id title).each { |k| attribute k, if: :admin? } would do the job without having to make
the implementation more complex than it needs.

[beauby]

excluded_attribute_keys might be a better name here.

[beauby]

A bit more work needed, but I'm personally favorable to this implementation. People are clearly expecting such a feature, and this appears to me as the sanest way to go around it.

[bf4]

IMHO, this needs to be much simpler. It introduces a lot of complexity (in understanding and maintaining the code, in addition to vectors for bugs) for what could be solved either by polymorphism or by some non-nil value that means 'remove this key'. A non-nil value that means 'include this key' is more complicated to consider.

[beauby]

The non-nil value that means 'exclude this key' puts too much of a burden on the user I think. Could you elaborate on the polymorphism solution? Do you mean subclassing the serializer into various flavors? If so, although I would personally go this way in my projects, several users have expressed their need for conditionally excluding many attributes depending on different conditions, which is a situation in which the polymorphism approach does not scale well (it takes an exponential number of serializers).

[bf4]

I don't think any library should do everything

[beauby]

@bf4 True, but since this library used to do exactly that, I think we need a better reason than that.

[bf4]

Just being philosophical here, but I'm not sure that a feature having been removed from a library is an argument that it belongs

[LcpMarvel]

I had updated the code. 😋 @beauby

[mrinterweb]

I was using the filter feature to protect attributes in my API. Now that it is gone in 0.10, is there a way to omit certain attributes? Am I supposed to have two serializers one with the attributes and one without? Should I have three serializers to replace this functionality, a base class serializer that the protected and non-protected serializers inherit from? I don't understand why we can't have filter or something like it again. Filtering out certain attributes is absolutely essential.

I need a solution to get this type of functionality back.

class UserSerializer < ActiveModel::Serializer
  attributes :id, :name, :email, :settings, :info, :token
  def filter(keys)
    unless object == scope
      keys -= [:settings, :email, :token]
    end
    keys
  end
end

If there is another way to omit keys based on the object and scope, I'd love to know. If there is no way to do this with 0.10 rc3, let me know and I'll downgrade.

[mrinterweb]

I found a solution that kind of works. My solution does not remove the attribute, but instead nullifies the value. I don't think this is a pretty solution, but it will have to do for now.

class UserSerializer < ActiveModel::Serializer

  [:email, :settings, :token].each do |a|
    define_method(a) do
      object == scope ? object.send(a) : nil
    end
  end

  attributes :id, :name, :email, :settings, :info, :token
end