Managing lifecycle of Notifiers when also rendering notifications on views/controllers

[sergioisidoro]

Hi,
First of all, thanks for the work on this gem. We've been using if for quite a long time :)

While migrating to 2.x we've come across some challenges, specifically about the default behaviour of saving the notification in the db. It makes sense, and we want to migrate to this way of doing things, but it comes with a challenge - Dynamically "rendering" messages like in the docs breaks things as data and code evolves. We would like hear your oppinion and perhaps help document this case.

eg. Let's imagine that we have a notification NewMessageNotifier, with a class method, and the same example as in the docs

class NewMessageNotifier < BaseNotifier
  notification_methods do
    def message
      t("newMessage.message", {messageTime: record.created_at, messageType: record.type})
    end
  end
end

And in a view:

<%= @user.notifications.last.message %>

Let's imagine now that we have a new version of the notifier, or that we don't need it anymore (no new notifications for this notifier) and delete NewMessageNotifier, or that message.type is no logner used and is dropped from the db. Things get strange. We always need to keep the notifiers backwards compatibilty if we want to keep a history of notifications.

The current architecture basically implies that once a Notifier is created (inc. translations) they cannot be delete or removed otherwise older notifications won'be be renderable anymore on a web view, or will be rendered differently than from when created.

In v1 we managed this by having a delivery method that would bypass the Notification model, and created a separare "rendered" model in the db that are basically strings. They no longer depend on any data, context, or translation keys.

class DeliveryMethods::NotificationLogger < Noticed::DeliveryMethods::Base
  def deliver
    NotificationLog.create(
      message: notification.message
    )
  end
end

This way we had a standard way of always rendering a message in the UI, regardless if the notifer no longer exists, translation key changes, etc. The obvious drawback is that the notfications are rendered at the time of delivery, so if the user changes their language it won't change the old notifications.

I'm guessing the "proper" way to do this now would be to create an extension to the Notification, add additional fields to the table with the migration, and use the recipient_attributes_for to generate additional attributes to the Notification object?

That is, at least, what I can read from here

noticed/app/models/concerns/noticed/deliverable.rb

Line 100 in fae78f9

notifications.insert_all!(recipients_attributes, record_timestamps: true) if recipients_attributes.any?

I'm wondering if someone else has encountered this issue, and how they resolved it?