draper/lib
Joe Rafaniello e79ae14518 Only Draper::Decorator types should delegate === to object. (#720)
Draper::Decorater provides the object method and we should delegate === to this
method only for these types.

Other classes could respond_to?(:object) so using is_a? clarifies not just any
class implementing object but only classes that are a Draper::Decorator.

Besides this, another major reason is is_a? is much faster than respond_to?
in ActiveRecord models because of the number of methods AR provides and the
layers of delegation. There is a cache specifically for respond_to? [1] because
it's so slow.

Even with this cache, some of our pages are 10% faster by using the is_a? change
from this patch.

The original implementation [2] used the method source, which was later renamed
to object.  The tests seem to indicate the intention was to always have
this === delegation to source/object for decorated objects... which is what
Drapper::Decorator types are.

Test changes:
* verify decorated instances of Product and instances derived from
decorated instances of Product are === Product.
* verify unrelated decorated instances and non-decorators that
happen to implement object are not === Product.

[1] https://github.com/rails/rails/blob/4-2-stable/activemodel/lib/active_model/attribute_methods.rb#L343-L351
[2] ca116154f3
2017-03-31 14:51:10 -05:00
..
draper Only Draper::Decorator types should delegate === to object. (#720) 2017-03-31 14:51:10 -05:00
generators Fix warnings with recent thor versions 2017-02-25 10:56:32 -03:00
draper.rb Add support for custom default controller configuration (#788) 2017-03-31 09:05:15 -05:00