CollectionDecorator#object returns Array instead of ActiveRecord::Relation after upgrading to 4.0.3

[saka-tsumikiinc]

Description

After upgrading from draper 4.0.2 to 4.0.3, CollectionDecorator#object returns an Array instead of ActiveRecord::Relation. This breaks code that calls ActiveRecord scopes on object within CollectionDecorator.

Steps to Reproduce

# Model
class Comment < ApplicationRecord
  scope :recent, -> { order(created_at: :desc) }
  scope :published, -> { where(published: true) }
end

# CollectionDecorator
class CommentsDecorator < Draper::CollectionDecorator
  def recent_published
    object.recent.published
  end
end

# Usage
post.comments.decorate.recent_published

Expected Behavior (4.0.2)

object is an ActiveRecord::Relation, so calling scopes like recent works correctly.

Actual Behavior (4.0.3+)

object is an Array, so calling scopes raises NoMethodError:

NoMethodError: undefined method `recent' for an instance of Array

Root Cause

This appears to be caused by PR #932, which introduced CollectionProxy#decorate:

  # lib/draper/decoratable/collection_proxy.rb
  def decorate(options = {})
    decorator_class.decorate_collection(load_target, options.reverse_merge(with: nil))
  end

load_target returns the cached association records as an Array, not the original ActiveRecord::Relation.

While this change improves performance by avoiding redundant database queries, it's a breaking change for code that relies on calling ActiveRecord methods on object.

Environment

• draper version: 4.0.3+ (works in 4.0.2)
• Ruby version: 3.3.7
• Rails version: 7.1.6

Possible Solutions

1. Document this as a breaking change
2. Provide an option to preserve the original Relation
3. Add method_missing to delegate unknown methods to the original relation (if stored separately)

Workaround

Currently pinning draper to version 4.0.2.

[Alexander-Senko]

@saka-tsumikiinc, thanks for the investigation! It looks like you've got the reason right.

Possible Solutions

1. Document this as a breaking change

I wouldn't like to loose the access to assiciation's scopes, etc. So, that's still a bug for me.

2. Provide an option to preserve the original Relation

Too sophisticated and leads to decorating an association twice in some cases.

3. Add method_missing to delegate unknown methods to the original relation (if stored separately)

Looks good from the user's point, but still too tricky & hacky inside 🤔

I've unloaded all the Draper logic off my mind already and thus need to recall it and think on the design again.

I'll check how my Magic Presenter handles that as well. It's designed to replace Draper (see the reasoning here).

[Alexander-Senko]

# lib/draper/decoratable/collection_proxy.rb
def decorate(options = {})
  decorator_class.decorate_collection(load_target, options.reverse_merge(with: nil))
end

Fast guess: wouldn't just replacing load_target with self help? 🤔

[saka-tsumikiinc]

Thank you for the quick response, @Alexander-Senko!
The self instead of load_target approach sounds promising and straightforward.
I'll also take a look at Magic Presenter as a potential alternative.

[saka-tsumikiinc]

I tested the proposed fix (replacing load_target with self) and it works!

The NoMethodError: undefined method 'xxx' for an instance of Array issue is resolved with this simple change.

Patch used for testing

# config/initializers/draper_collection_proxy_patch.rb
module Draper
  module Decoratable
    module CollectionProxy
      def decorate(options = {})
        decorator_class.decorate_collection(self, options.reverse_merge(with: nil))
      end
    end
  end
end

The simple change from load_target to self resolves the issue.

[Alexander-Senko]

@saka-tsumikiinc, it sounds great if it doesn't break other tests. Would you make a PR then?

[Alexander-Senko]

...if it doesn't break other tests.

Or, if it does, you can keep it as a local patch until the issue is resolved.