Custom Adapter for Overriding root key

[sbauch]

I'm in the process of upgrading to 0.10.0.rc2. I'm a little bit inconsistent throughout the client app in terms of whether to expect a root or not, something I'll eventually get around to fixing.

But for now I need the functionality present in previous versions that allow me to pass a :root option, including nil to a serializer in order to customize or remove the root key from a json result.

So I think I want the ActiveModel::Serializer::Adapter::Json but with the ability to override the root key.

I went ahead and took a stab at implementing this, hoping someone can provide a little bit of feedback for it and let me know whether there's a more efficient way to achieve what I'm looking to do

module My
  class CustomAdapter < ActiveModel::Serializer::Adapter::Json

    def serializable_hash(options = nil)
      json = super(options)

      if options.keys.include?(:root)
        if options[:root]
          {options[:root] => json[root]}
        else
          json[root]
        end
      else
        json
      end
    end
  end
end

[NullVoxPopuli]

you can specify which adapter to use per-request.
So, if you didn't want a root, you could use 'adapter: :flatten_json`

[sbauch]

right, that would help, but I still want to customize the root key in other places (i.e. change it from photos: {...} to, for example, images: {...}

it seems like a custom root key is only possible with the JSONAPI adapter, which sounds like a smart thing to use, but at the moment would be a pretty major refactor for my client app.

[NullVoxPopuli]

Could you make a test for the json adapter for specifying a root as a render option?

something like this: render json: @object, serializer: SomethingSerializer, root: 'custom'

[sbauch]

ah, okay, I was definitely wrong!

@NullVoxPopuli sorry, I'm not sure what you're asking. To write a test for the library and submit a PR that ensures rendering as you suggested returns json with a root of "custom"?

I'm actually now using a custom adapter based off of the NestedJson adapter proposed in #1073, which is really a separate issue (I needed to nest more associations than the :json adapter seemed to want to do).

But to go a little deeper on my original question, given your suggestions I could:

no root:
render json: @photo, serializer: PhotoSerializer, adapter: :flatten_json

custom root:
render json: @Photo, serializer: PhotoSerializer, adapter: :json, root: 'profile_image'

so the thing that threw me for a loop is that this does not behave as I might expect:

render json: @photo, adapter: :json, serializer: PhotoSerializer, root: nil
=> {'photo': {...}}

I would instead expect rootless response.

[NullVoxPopuli]

Just for clarification: you're saying are are not having a problem with root: 'profile_image'? but you experience a problem / unexpected behavior with root: nil?

[thiagogabriel]

I need a custom root because my collection is a STI, so the root can many things.
I tried a custom root but it doesn't work on rc2, even on the render. The solution for my problem was to set flatten_json adapter on the render, so it will not appear "random" root keys on STI collection.

[NullVoxPopuli]

I just made this really quick passing test:

class NamespacedProfile < Model
end

class NamespacedProfileSerializer < ActiveModel::Serializer
  attributes :id
end
module Api
  module V1
    class NamespacedTestController < ActionController::Base
      def render_using_default_adapter
        profile = NamespacedProfile.new({id: 1, name: 'Name 1', description: 'Description 1', comments: 'Comments 1' })
        profiles = [profile]
        render json: profiles, root: 'test', adapter: :json
      end
    end
  end
end

tests Api::V1::NamespacedTestController

def test_render_using_adapter_override
  get :render_using_default_adapter

  expected = {
    tests: [{ id: 1 }]
  }

  assert_equal expected.to_json, response.body
end

This is on master.

can you see if you can set the root on master?

interestingly enough, when I set the root to nil, I got this for the root:

'action_controller/serialization/namespaced_controller_test/namespaced_profiles'

so... not sure if that should be considered a bug, as it's the fully qualified name of the serializer - it's just... long and awkward.

@thiagogabriel is there anyway you can fork AMS, and implement some tests on the controller to simulate your scenario? I think I'm doing something wrong.

[thiagogabriel]

@NullVoxPopuli All bugs I found are fixed on master but it was broken on rc2 and I couldn't test on rc3 due to another bug.

[NullVoxPopuli]

That's great news!