Make ApplicaitonDecorator work as Dekorator::Base do.

Maybe adding something like

See:
https://github.com/komposable/dekorator/blob/b037876988dd5416257855719edf6ddd6bb47c10/lib/dekorator.rb#L98C9-L98C9

- return false if object_or_enumerable.is_a?(Dekorator::Base)
+ return false if object_or_enumerable.abstract_class? || object_or_enumerable == Base

And have abstract_class? method like `ActiveRecord does.

• Update README
• Update badges
• Update gemspec

Choose a new CI service (CircleCI) to replace TravisCI

Create a benchmark to check performances

(example)

• Ignore useless files for gem build.

Update tests, Appraisals, gemspec, CI config, ... .

We should update the Railtie to update the autoload path as following.

config.after_initialize do |app|
  app.config.paths.add 'app/decorators', eager_load: true
end

Use combustion gem to make more tests with a Rails application.

Maybe re-use DecoratedEnumerableProxy

Does #decorate should be accessible in ApplicationController?
From where #decorate should be available?

class UserController < ApplicationController
  def index
    @users = decorate User.all
  end
end

decorate(decorate(Post.new)) should not decorate the decorated object.

def decorate(object_or_collection, with: nil)
  return object_or_collection if object_or_collection.blank? || object_or_collection.is_a?(Dekorator::Base) || object_or_collection.is_a?(DecoratedEnumerableProxy)

  ...
end

Since the latest release of ActiveAdmin allow to use PORO decorator, we may clean some part of dekorator code.

activeadmin/activeadmin#6249

Hey there,

playing with dekorator for the first time. I was exploring the source code and found the following method:

I'm interested in the design decision for object_or_enumerable.respond_to?(:empty?) && object_or_enumerable.empty?. I see how it can be useful for basic arrays (although iterating over an empty array isn't bad either), but when passing an AR Relation, that line will perform an additional query:

[1] pry(main)> Dekorator::Base.decorate(User.all)
  User Exists? (0.6ms)  SELECT 1 AS one FROM "users" LIMIT $1  [["LIMIT", 1]]
  User Load (0.4ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT $1  [["LIMIT", 1]]

[2] pry(main)> Dekorator::Base.decorate(User.all.to_a)
  User Load (0.5ms)  SELECT "users".* FROM "users"

Is that intended behaviour?

• Do specs to test dekorator:install and decorator generators.
• Generate a dummy_app one time, then duplicate it to do tests from scrash

Does a concern could be a nice to have for model to access decorated object by itself.

Something like

module Decorable
  def decorated
    @decorate ||= decorate_class.decorate(self)
  end

  def decorator_class
    @decorator_class ||= "#{object_or_enumerable.class}Decorator".safe_constantize
  end
end

So in a model

class User < ApplicationRecord
  include Decorable
  ...

  def decorator_class
    CustomDecorator
  end
end

user = User.first # => User
user.decorated # => CustomDecorator

May we remove rails dependencies? That way this gem could be used alone.

• Add more examples
• Testing section

In #28 we implement a benchmark and did some optimization.

I think our benchmark could be improved. It the first time I did one, so I'm sure it's not perfect.

Explain why we did this gem on README.

The main reason is: having something light compare to draper and after the presentation of @benoittgt about "Ruby memory, ActiveRecord and Draper" (https://medium.com/appaloosa-store-engineering/ruby-memory-activerecord-and-draper-64f06abeeb34).

• Configure travis-ci
• Add badge

configuration

• Use appraisal to manage different rails versions.
• Use simplecov