{"action":"created","issue":{"url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/760","labels_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/760/labels{/name}","comments_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/760/comments","events_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/760/events","html_url":"https://github.com/rails-api/active_model_serializers/issues/760","id":51897995,"number":760,"title":"0.10 - ADAPTER_OPTION_KEYS is too limiting.","user":{"login":"jejacks0n","id":13765,"avatar_url":"https://avatars.githubusercontent.com/u/13765?v=3","gravatar_id":"","url":"https://api.github.com/users/jejacks0n","html_url":"https://github.com/jejacks0n","followers_url":"https://api.github.com/users/jejacks0n/followers","following_url":"https://api.github.com/users/jejacks0n/following{/other_user}","gists_url":"https://api.github.com/users/jejacks0n/gists{/gist_id}","starred_url":"https://api.github.com/users/jejacks0n/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jejacks0n/subscriptions","organizations_url":"https://api.github.com/users/jejacks0n/orgs","repos_url":"https://api.github.com/users/jejacks0n/repos","events_url":"https://api.github.com/users/jejacks0n/events{/privacy}","received_events_url":"https://api.github.com/users/jejacks0n/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2014-12-13T20:04:40Z","updated_at":"2015-01-06T12:13:18Z","closed_at":null,"body":"This should be moved into the Adapter layer, and should not happen at the controller level.\r\n\r\nThis is because of the unlimited nature of what options an adapter might want to take, and how `:include` could be expanded upon to also provide `:exclude` -- so in general, it seems like it might be better to pass all options to the adapter layer, and the adapter should be able to mutate the options that are then provided to the serializer.\r\n\r\nThis provides a much better structure for options to be handled by the adapter layer, while still making it into the serializer layer -- if applicable.\r\n\r\nMy thinking is that the adapter should be instantiated *before* the serializer (in the ActionController `_render_*` methods), which allows the options to be mutated by the adapter. Then the serializer should be instantiated with the potentially mutated options, and provided to the adapter via a standard API.\r\n\r\nThis would make it read more like (psuedo code):\r\n\r\n```ruby\r\n  def default_serializer_options\r\n    {}\r\n  end\r\n\r\n  [:_render_option_json, :_render_with_renderer_json].each do |renderer_method|\r\n    define_method renderer_method do |resource, options|\r\n      @_serialization_options = default_serializer_options.merge(options) # restore 0.8 functionality\r\n\r\n      if use_adapter? && (serializer = get_serializer(resource))\r\n        adapter = ActiveModel::Serializer::Adapter.create(@_serialization_options)\r\n        adapter.set_serializer(serializer.new(resource, @_serialization_options))\r\n        super(adapter, options)\r\n      else\r\n        super(resource, options)\r\n      end\r\n    end\r\n  end\r\n```"},"comment":{"url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/comments/68858201","html_url":"https://github.com/rails-api/active_model_serializers/issues/760#issuecomment-68858201","issue_url":"https://api.github.com/repos/rails-api/active_model_serializers/issues/760","id":68858201,"user":{"login":"kurko","id":70312,"avatar_url":"https://avatars.githubusercontent.com/u/70312?v=3","gravatar_id":"","url":"https://api.github.com/users/kurko","html_url":"https://github.com/kurko","followers_url":"https://api.github.com/users/kurko/followers","following_url":"https://api.github.com/users/kurko/following{/other_user}","gists_url":"https://api.github.com/users/kurko/gists{/gist_id}","starred_url":"https://api.github.com/users/kurko/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kurko/subscriptions","organizations_url":"https://api.github.com/users/kurko/orgs","repos_url":"https://api.github.com/users/kurko/repos","events_url":"https://api.github.com/users/kurko/events{/privacy}","received_events_url":"https://api.github.com/users/kurko/received_events","type":"User","site_admin":false},"created_at":"2015-01-06T12:13:18Z","updated_at":"2015-01-06T12:13:18Z","body":"I agree with you, @jejacks0n. I implemented some options that were needed by JsonApi adapter and it felt very dirty to have those options being managed by the serializer. I've seen adapters in other languages using this dependency direction and it was way cleaner. So if you could craft a PR, I'd definitely support it.\r\n\r\ncc @steveklabnik could you chime in if this kind of refactoring is something you see as a benefit, or would you rather keep the current dependency direction?"}}