Custom business logic on create or update

[coatezy]

I was wondering if there are any recommended patterns for calling custom business logic such as service objects when creating or updating resources. In a couple instances I've overridden #save_record_action to add necessary business logic on save but I was wondering if there was a better approach?

Example:

class Avo::VideosController < Avo::ResourcesController
  def save_record_action
    if @record.new_record?
      handle_upload
    end

    super
  end

  private

  ...
end

[Paul-Bob]

Your approach should work but we didn't document that method as an exposed API, you can keep it but it can change

What I recommend is to use the exposed methods from the documentation https://docs.avohq.io/3.0/controllers.html

For example for a callback on success creation:

class Avo::VideosController < Avo::ResourcesController
  def create_success_action
    @record.created_from_avo

    super
  end
end

This applies when you want certain callbacks to trigger only when a record is created through Avo. For a more universal solution, I recommend using Active Record callbacks.

[coatezy]

Ahh yes create_success_action would work well if I wanted to perform an action after the resources was successfully persisted. That said, I've implemented Devise invitable which requires #invite! instead of #save to be called so #create_success_action it likely going to be too late. I.e:

  def save_record_action
    @record.invite! do |u|
      u.skip_invitation = true
      u.invited_by = current_user
    end

    @record
  end

[Paul-Bob]

Nothing wrong with your approach with the save_record_action override, but according to invitable documentation:

You can send an invitation to an existing user if your workflow creates them separately

You can do @record.invite! on the record even after it's already created by a normal save method.

I always recommend the usage of documented API since it's less probable to change or break things unexpectedly

If you set a test case for your approach you should be covered as well!

[coatezy]

Totally agree on documented public APIs. Another consideration is database level constraints and/or active record validations. There may be a required or not nullable field that is not populated by the user but programmatically by the application on save. Without handling before save the record will fail to validate or will rollback at a database level if a constraint is not satisfied. For example, with Devise there is password and password confirmation validation which is skipped when the invitable invite! method is called on a new record. Alternatively if a temporary secure password were to be set this would also need to be set before calling my save. It would be great if a public API could be exposed to facilities these types of requirements. For now I'll live life dangerously and take the risk. 🙌

[Paul-Bob]

It would be great if a public API could be exposed to facilities these types of requirements.

Overriding save_record_action fits perfectly for your situation right? IMO save_record_action and destroy_record_action are abstracted enough to be exposed and documented.