Allow Associated Objects to extend their Active Record

[kaspth]

If we eager load the Associated Object class when calling has_object we can have an extension class method fire that can extend the Active Record class.

class Post::Publisher < ActiveRecord::AssociatedObject
  extension do
    has_many :contracts, dependent: :destroy

    after_create_commit :publish_later_after_signed

    private def publish_later_after_signed
      # An integrating method that operates on `publisher`.
      # A little tough to generate an example since we're now mixing in a `contracts` concept.
      publisher.publish_later if contracts.all?(&:signed?)
    end
  end
end

I'm still not quite sure how I feel about this. I'll write some documentation later, after I've sat with this some more.

@garrettdimon this doesn't quite get us to the automatically scoped validations, but is this closer to what you were talking about with replacing those wrapping ActiveSupport::Concerns ala kaspth/conventional_extensions?

@natematykiewicz is this something that would be useful to you? Does this seem clear enough? Would it break your app if we eager-loaded the Associated Objects (due to autoloading it should be fine)?

[kaspth]

@seanpdoyle have you tried using this gem yet? Would this be something you'd be interested in?

[natematykiewicz]

I'm not sure if I'd use that feature or not, but it makes sense. Also, I think this feature or not, we should eager load (when eager loading is enabled) AssociatedObject and ActiveJob Performs classes. If they aren't eager loaded in production, we'd end up using more memory than necessary.

[natematykiewicz]

Also, I don't think this would cause me any problems. I've assumed they work like models where they're eager loaded in production and lazy loaded in development. If not, I think we should change that.

[garrettdimon]

I think I'd have to tinker with it and see how it feels, but just looking at it, it sure seems like a good approach.

[kaspth]

@garrettdimon nice! There's also no rush on this, so take your time. I wonder how we explain it to people, since it could be a bit hidden. I could see an alias_method :has_extending_object, :has_object to help clarify that something happens in the other file. Of course, post.method(:<something>).source_location still points to the right location.

[kaspth]

I'm not sure if I'd use that feature or not, but it makes sense. Also, I think this feature or not, we should eager load (when eager loading is enabled) AssociatedObject and ActiveJob Performs classes. If they aren't eager loaded in production, we'd end up using more memory than necessary.

@natematykiewicz we're just leaning on app/models being set up for eager-loading so both Associated Objects and ActiveJob::Performs will be eager-loaded when the app is.

Also, I don't think this would cause me any problems. I've assumed they work like models where they're eager loaded in production and lazy loaded in development. If not, I think we should change that.

Yeah, that's how it works before this PR. However, if we shift to loading the Associated Object when has_object is called, then we can inject extensions into the record class — and obviate some needs for wrapping ActiveSupport::Concerns.

Basically, using the example from the description, before this PR it'd be common to do something like this:

# app/models/post.rb
class Post < ApplicationRecord
  include Published
end

# app/models/post/published.rb
module Post::Published
  extend ActiveSupport::Concern

  included do
    has_many :contracts, dependent: :destroy

    has_object :publisher
    after_create_commit :publish_later_after_signed
  end

  private def publish_later_after_signed
    publisher.publish_later if contracts.all?(&:signed?)
  end
end

So we're splitting the extension/integration into a wrapping Concern, but what if we could bundle that into the Associated Object now that they're a domain concept and we're already using them? It gets tricky though, especially communicating where things come from.

[natematykiewicz]

I realized yesterday that I'd probably move the callbacks inside the extension block. I use associated objects with activerecord callbacks a lot. Oftentimes its after_create_commit and then an after_update_commit if saved_change_to some field(s). The after_create_commit doesn't have conditions, the code often looks like:

# model
has_object :foo, after_create_commit: :sync_later
after_update_commit -> { foo.sync_later }, if: :saved_change_to_active?

But with extensions I'd probably just switch that to:

# model
has_object :foo

# associated object
extension do
  after_create_commit -> { foo.sync_later }
  after_update_commit -> { foo.sync_later }, if: :saved_change_to_active?
end

Ship it, Kasper!

[kaspth]

@natematykiewicz nice! Sounds good, I think I'll ship this after we get #20 in then, and cut a new release.

[natematykiewicz]

@kaspth in your rebase, you lost the eager loading of the associated object class.