Problem or use case

The use case that explains this feature is for those applications which want to keep the track of notifications even if a notifiable has been destroyed. With the current implementation, we can skip deletion of dependent notifications by not passing any parameter to dependent_notifications (on acts_as_notifiable), which is the default behavior but in this case this results in having the notifiable_type and notifiable_id pointing to an unexisting record. Even if this is a correct approach, some cases needs to clean this kind of information. That's where the option of nullify_notifiable comes to action.

Expected solution

Steps to follow:

1. Adding a new option to available_dependent_notifications_options called nullify_notifiable.
2. Adding a new option to add_destroy_dependency for that key we defined before.
3. Defining into the Notifiable module the new function which will update all the generated_notifications_as_notifiable_for(target_type) to notifiable_type and id to nil.

Alternatives

For this approach I did not find any easy way to do this without monkeypatching, which has been the solution I've took.