17、回调函数的使用与优化

回调函数的使用与优化

1. 持久化模块与表单生命周期

在处理表单操作时，我们常常需要判断对象是新创建的还是已存在的，以便进行不同的处理，比如向作者发送正确的邮件通知。这里就涉及到持久化模块（Persisted Module）的使用。

表单实际上是具有验证语义的 Twin 对象。表单的 API 非常简单，主要分为以下三个步骤：
1. 实例化 ：表单从装饰的模型中获取值来填充其属性，这一行为继承自 Twin，而非 Reform 实现。
2. 验证 ：调用 validate 方法会更新属性值，并可能向嵌套表单属性添加更多对象，这是 Reform 提供的唯一功能。
3. 保存 ：验证成功后，使用 save 方法将数据写回模型，这在 Twin 中实现。

表单或 Twin 的这种简单生命周期使得跟踪更改变得容易。例如，通过利用每个表单自动包含的 Persisted 模块，我们可以轻松判断模型在保存时是否已持久化。示例代码如下：

thing = Thing.new
form = Thing::Form.new(thing)
form.persisted? #=> false
form.save
form.persisted? #=> true

每个表单，包括嵌套表单，都可以通过 persisted? 方法报告模型的持久化状态。

2. 判断对象是否新创建

仅判断模型是否持久化还不够，我们还需要知道用户是刚刚创建的还是几个月前就已存在。这时，Twin 跟踪字段更改的特性就派上用场了。Persisted 模块提供了 created? 方法，它通过检查 persisted? 在调用 save 时是否发生变化来判断装饰的模型是否刚刚创建。示例如下：

form.save
form.created? #=> true

如果是已存在的对象， created? 方法将返回 false ：

thing = Thing.find(1)
form = Thing::Form.new(thing)
form.save
form.created? #=> false

3. 显式回调

利用 created? 方法，我们可以在创建操作中实现第一个真正的回调。例如，根据用户是否新创建来发送不同的邮件通知：

def notify_authors!
  contract.users.collect do |user|
    if user.created?
      NewUserMailer.welcome_email(user.model)
    else
      ExistingUserMailer.added_email(user.model)
    end
  end
end

这里需要注意的是，我们在回调方法中操作的是 contract 而不是直接操作模型，这样可以利用 Twin 的 API。

另外，我们还需要重新添加 reset_authorships! 函数，用于将所有新创建的 Authorships 设置为未确认状态。最初的实现如下：

def reset_authorships!
  model.authorships.each { |aship| aship.update_attribute(:confirmed, 0) }
end

但这个方法在更新操作中会有问题，因为它会将所有 Authorships 重置为未确认状态，即使是之前已确认的。为了解决这个问题，我们可以使用 Twin 的另一个特性：

class Thing::Create < Trailblazer::Operation
  def reset_authorships!
    contract.users.each do |user|
      next unless contract.users.added.include?(user)
      user.model.authorship.update_attribute(:confirmed, 0)
    end
  end
end

通过检查用户是否是新添加的，我们可以避免不必要的重置操作。

在操作的 process 方法中，我们可以显式地触发这些回调：

def process(params)
  validate(params[:thing]) do |f|
    f.save
    notify_authors!
    reset_authorship!
  end
end

4. 显式回调的继承问题

由于 Update 操作继承自 Create 操作，它会继承相同的回调集。对于通知回调，这仍然可以正常工作，但 reset_authorship! 回调在更新操作中会出现问题。我们可以通过在 Update 操作中重写该方法来解决，或者使用 on_change 事件来简化操作：

class Thing::Create < Trailblazer::Operation
  callback do
    on_change :expire_cache!
  end
end

5. 命令式回调

在 Rails 中，回调通常在预定义的事件（如 before_validation 或 after_save ）发生时自动触发，开发者无法完全控制其执行时间。而在 Trailblazer 中，我们可以完全跳过定义生命周期事件，通过显式触发钩子或简单方法来运行回调，这被称为命令式回调。

例如，在验证之前运行回调：

def process(params)
  comments_count_ok? # before validate.
  validate do
    # ..
  end
end

6. 回调分组

Trailblazer 允许将回调逻辑分组，使复杂的后处理代码结构更加清晰。例如：

class Thing::Create < Trailblazer::Operation
  callback do
    collection :users do
      on_add :notify_author!
      on_add :reset_authorship!
    end
    on_create :expire_cache!
  end
end

通过调用 dispatch! 方法，我们可以触发默认组中的所有回调：

def process(params)
  validate(params) do |f|
    f.save
    dispatch!
  end
end

当调用 dispatch! 时，回调将按以下顺序执行：
1. 检查 users 集合中新增的项，并为每个项调用 notify_author! 方法。
2. 再次检查新增项，为每个项调用 reset_authorship! 方法。
3. 由于顶级对象被认为是“新创建的”，调用 expire_cache! 方法。

7. 回调测试

在进行回调测试时，我们可以将测试代码包含在操作测试中。例如，在 ThingCrudTest 中有一个测试用例，它运行一个有效的操作并添加两个用户，同时检查 Authorship 的确认状态：

it do
  # ..
  # authorship is not confirmed, yet.
  model.authorships.pluck(:confirmed).must_equal [0, 0]
  op.invocations[:default].invocations[0].must_equal
    [:on_add, :notify_author!, [op.contract.users[0], op.contract.users[1]]]
end

这个测试确保了 :reset_authorship! 回调的正确性，同时也对 :notify_author! 回调进行了基本测试。

综上所述，通过使用 Twin 对象和回调分组，我们可以更灵活、更清晰地处理表单操作和后处理逻辑，同时通过测试确保代码的正确性。

以下是表单操作的流程图：

graph TD;
    A[实例化表单] --> B[验证表单];
    B --> C{验证是否成功};
    C -- 是 --> D[保存表单];
    C -- 否 --> B;
    D --> E[触发回调];

以下是回调执行顺序的表格：
| 步骤 | 操作 | 说明 |
| ---- | ---- | ---- |
| 1 | 检查 users 集合新增项 | 调用 notify_author! 方法 |
| 2 | 再次检查 users 集合新增项 | 调用 reset_authorship! 方法 |
| 3 | 检查顶级对象状态 | 调用 expire_cache! 方法 |

回调函数的使用与优化

8. 回调分组的灵活性与继承

回调分组不仅提供了清晰的结构，还具有很高的灵活性。在 Trailblazer 中，我们可以在子类操作中对回调分组进行修改和扩展。

例如， Update 操作继承自 Create 操作，默认会继承其回调分组。但对于 on_create 回调，在 Update 操作中不会触发，因为我们是在更新而不是创建对象。此时，我们可以在 Update 操作中添加 on_update 回调：

class Thing::Update < Trailblazer::Operation
  callback do
    on_update :expire_cache!
  end
end

不过，为了简化操作，我们可以使用 on_change 事件，它可以同时处理创建和更新操作：

class Thing::Create < Trailblazer::Operation
  callback do
    # ..
    on_change :expire_cache!
  end
end

这样，无论是创建还是更新操作， expire_cache! 方法都会在合适的时候被调用。

此外，我们还可以将回调分组定义在单独的类中，实现继承、扩展和重用。示例如下：

class AfterSave < Disposable::Callback::Group
  on_change :refresh!
end

class Thing::Create < Trailblazer::Operation
  self.callbacks[:default] = AfterSave
end

这种方式使得回调分组更加模块化，便于管理和维护。

9. 回调方法的实现细节

在回调分组中定义的回调方法，通常会在操作实例上被调用。下面详细介绍几个回调方法的实现。

notify_author! 方法用于根据用户是否新创建发送不同的邮件通知：

class Thing::Create < Trailblazer::Operation
  def notify_author!(user)
    return UserMailer.welcome_and_added(user, model) if user.created?
    UserMailer.thing_added(user, model)
  end
end

该方法接收一个嵌套表单对象 user ，通过 created? 方法判断用户是否新创建，然后调用相应的邮件发送方法。

reset_authorship! 方法用于将新添加用户的 authorship 状态重置为未确认：

def reset_authorship!(user)
  user.model.authorships.find_by(thing_id: model.id).update_attribute(:confirmed, 0)
end

此方法通过 user.model 获取实际的 User 实例，然后找到对应的 authorship 模型，并将其 confirmed 字段设置为 0。

10. 回调测试的重要性与实践

在开发过程中，回调测试是确保代码正确性的关键环节。我们应该将回调测试包含在操作测试中，以保证测试环境与生产环境的一致性。

不建议在测试中关闭回调，因为回调通常会产生副作用，如设置标志或改变应用状态。跳过回调测试会导致测试环境与实际情况不符，可能会使一些问题在生产环境中才被发现。

例如，在 ThingCrudTest 中的测试用例，既检查了 :reset_authorship! 回调对 authorship 确认状态的影响，又对 :notify_author! 回调进行了基本测试：

it do
  # ..
  # authorship is not confirmed, yet.
  model.authorships.pluck(:confirmed).must_equal [0, 0]
  op.invocations[:default].invocations[0].must_equal
    [:on_add, :notify_author!, [op.contract.users[0], op.contract.users[1]]]
end

通过这种方式，我们可以确保回调在整个操作流程中正常工作。

11. 总结与展望

通过使用 Twin 对象和回调分组，我们能够更灵活、更清晰地处理表单操作和后处理逻辑。Twin 的跟踪功能使得我们可以轻松判断对象的状态变化，从而实现精确的回调控制。回调分组则将复杂的后处理代码进行了有效的组织，提高了代码的可读性和可维护性。

在未来的开发中，我们可以进一步探索回调分组的更多应用场景，如根据不同的业务需求动态调整回调分组，或者结合其他技术实现更复杂的业务逻辑。同时，持续进行回调测试，确保代码的稳定性和可靠性。

以下是回调分组继承与扩展的流程图：

graph TD;
    A[Create 操作回调分组] --> B[Update 操作继承回调分组];
    B --> C{是否需要修改};
    C -- 是 --> D[添加/修改回调];
    C -- 否 --> E[使用默认回调];
    D --> F[完成 Update 操作回调分组];
    E --> F;

以下是回调方法及其功能的表格：
| 回调方法 | 功能 |
| ---- | ---- |
| notify_author! | 根据用户是否新创建发送不同的邮件通知 |
| reset_authorship! | 将新添加用户的 authorship 状态重置为未确认 |
| expire_cache! | 在对象创建或更新时使缓存失效 |