`.find` on a namespaced decorator class fails if there is not a "base" inferrable decorator class

[julioag-rmd]

Env

• Affected versions: 4.0.5, 4.0.6
• Unaffected version: 4.0.4
• Rails Version: 8.0.3
• Ruby Version: 3.4.8

Context and Issue

I use decorators under namespaces to provide logic depending on the application context. Eg: Admin:: namespaced decorators are to use inside our admin namespace, API::V1:: namespaced decorators are for use in API v1, etc.

There may be decorators on the root app/decorators folder, there may be not.

NOTE I am not using inheritance between decorators, as in, all inherit from Draper::Decorator.

Eg:

Admin::EncounterDecorator < Draper::Decorator and EncounterDecorator < Draper::Decorator.

So, given this setup on a Rails app

app/models/encounter.rb
app/models/consult.rb
app/decorators/encounter_decorator.rb
app/decorators/admin/encounter_decorator.rb
app/decorators/admin/consult_decorator.rb

👀 Notice how there is no app/decorators/consult.rb

In a Rails console:

> EncounterDecorator.find(2134)
  Encounter Load (0.8ms)  SQL blabla
=> #<EncounterDecorator:0x0000000135d32300
 @context={},
 @object=
  #<Encounter:0x000000013589ac98
   id: 1127442,

and

> Admin::EncounterDecorator.find(2134)
  Encounter Load (0.8ms)  SQL blabla
=> #<Admin::EncounterDecorator:0x0000000135d32300
 @context={},
 @object=
  #<Encounter:0x000000013589ac98
   id: 1127442,

All good so far, but:

> Admin::ConsultDecorator.find(4321)
  Consult Load (0.8ms)  SQL bla bla
Draper::UninferrableDecoratorError: Could not infer a decorator for Consult. (Draper::UninferrableDecoratorError)

          raise Draper::UninferrableDecoratorError.new(called_on)
          ^^^^^
from /Users/julio/.local/share/mise/installs/ruby/3.4.8/lib/ruby/gems/3.4.0/gems/draper-4.0.6/lib/draper/decoratable.rb:87:in 'Draper::Decoratable::ClassMethods#decorator_class'

Expected Behavior

If the class is a decorator itself, there's no attempt at inferring a defaut decorator, and the class itself is the decorator class?

Question

Or, is it intended/expected/enforced that there is an app/decorators/consult_decorator.rb and namespaced decorators inherit from it?

[unavailabl3]

Just was raising similar issue 👍 Context from my side:
[4.0.6] GlobalID support breaks when decorators are in different namespaces than their models

Draper 4.0.5+ introduced GlobalID support allowing decorated objects to be serialized and deserialized while maintaining decoration. However, this breaks when decorators are in different namespaces than their underlying models, which is a common pattern for organizing decorators by context (e.g., Dashboard::, Api::).

The Problem
The new implementation assumes decorator namespaces match model namespaces, causing Draper::UninferrableDecoratorError when they don't.

Example Structure (Common Pattern)

# Model (root namespace)
class Event < ApplicationRecord
end

# Decorator (namespaced by context)
module Dashboard
  module Events
    class Decorator < Dashboard::ApplicationDecorator
      # decorates Event model
    end
  end
end

What Breaks

1. Decorator.find(id) fails:

Dashboard::Events::Decorator.find(1)
# Error: Draper::UninferrableDecoratorError: Could not infer a decorator for Event.

2. GlobalID::Locator.locate fails:

decorator = Dashboard::Events::Decorator.decorate(event)
gid = decorator.to_global_id.to_s
# => "gid://app/Dashboard::Events::Decorator/1"

GlobalID::Locator.locate(gid)
# Error: Draper::UninferrableDecoratorError: Could not infer a decorator for Event.

Environment

• Draper: 4.0.6
• Rails: 8.1.2
• Ruby: 3.2.0

[Alexander-Senko]

A quick guess without any debugging yet, here could be the cause:

draper/lib/draper/compatibility/global_id.rb

Line 21 in e8421b7

object_class.find(*args).decorate

This code should be consistent with Draper::Finders.

Normally you should not get any finders until you explicitly ask for, as the docs say. You should use decorates_finders first.

So, formally, failing .find without decorates_finders is not a bug. A functioning one actually is.

If you prefer a cleaner API & architecture, try looking at my Magic Presenter alternative (see the reasons here).

[julioag-rmd]

@Alexander-Senko

First, thanks for the fast response!

So, formally, failing .find without decorates_finders is not a bug. A functioning one actually is.

Didn't know about decorates_finders until now. Gotta RTFM ha.

Adding it to some of the decorators solves my problem I think!

In any case, assuming I have a namespaced decorator AND NOT an unnamespaced decorator for a model, without decorates_finders, should maybe read more like this:

Admin::ConsultDecorator.find(123)
Draper::UndecoratedFinderMethodCalledError: undecorated finder method of decorated class called. Use `decorates_finders` in Admin::ConsultDecorator

However, after I add decorates_finders to the namespaced decorator:

Admin::EncounterDecorator.find(123213).decorator_class
  Encounter Load (1.0ms)  SELECT blabla SQL
Draper::UninferrableDecoratorError: Could not infer a decorator for Consult. (Draper::UninferrableDecoratorError)

          raise Draper::UninferrableDecoratorError.new(called_on)
          ^^^^^

Not gonna do this in the code, but sill it should return Admin::EncounterDecorator, right?

[Alexander-Senko]

Draper::UndecoratedFinderMethodCalledError: undecorated finder method of decorated class called. Use `decorates_finders` in Admin::ConsultDecorator

The bug is fixed easily by copying .find's code from Finders to GlobalID, but I don't like the copy-paste strategy. I could withstand a non-DRY one-liner though, as Draper is a mess already.

Users seem to prefer all the API mess be kept in, so there's a little chance of Draper be refactored to be further developed. I started that discussion but got no responses ever since.

[Alexander-Senko]

Draper::UninferrableDecoratorError: Could not infer a decorator for Consult. (Draper::UninferrableDecoratorError)

Not gonna do this in the code, but sill it should return Admin::EncounterDecorator, right?

It should not. When you get the model from .find it's just a model. There's no history to trace the decorator used for that back, or whether one has ever been.

Better inference could solve some cases. Magic Decorator is much more flexible in this case, so it's technically possible for Draper as well.

[julioag-rmd]

It should not. When you get the model from .find it's just a model.

True, I had assumed EncounterDecorator.find(x) would "find and decorate", so it would return an EncounterDecorator, not an Encounter, as it turns out to do.

This does not make much sense to me, tbqh. I am starting to feel that finders decoration is something to stay away from...

At this point, I'd say the only issue is then that if I would expect that if I call decorated_class on a decorated object, it returns the decorator currently applied to the object, not the inferred decorator.

But again, this may be because some wrong assumption on my side... let me know

> decorated_encounter = Admin::EncounterDecorator.decorate(Encounter.first)

# if there is a "root" EncounterDecorator
> decorated_encounter.decorator_class
# => Admin::EncounterDecorator # expected behavior
# => EncounterDecorator # current, buggy behavior

# if there is NOT a "root" EncounterDecorator
> decorated_encounter.decorator_class
# => Admin::EncounterDecorator # expected behavior
# => Draper::UninferrableDecoratorError # current, buggy behavior

or even

> decorated_encounter = Admin::EncounterDecorator.decorate(Encounter.first)
> decorated_encounter.decorator_class
# => NoMethodError

Since applied_decorators does just what I expect decorator_class to do in this case

[Alexander-Senko]

When you get the model from .find it's just a model.

My fault. For sure, it should be decorated. But you don't need to call #decorator_class as it's already a decorator. Just #class is enough here.