I gave a talk about "Modularizing with Packwerk" at the local "Ruby Montevideo" Meetup last month

General
3

Hi Stephan,

…I am curious if you found that it feels to folks like the domain gets split into two places?

A bit, yes. In particular, I would like to avoid the need of the initializer code to support dependency callbacks. I feel like it should be possible to do this from the belongs_to declaration itself.

In my slide 32 I feel like, Ideally, I should be able to do this instead of adding the code to the initializer:

class Enrollment
  # This is what I would like to be able to do,
  # indicating that all enrollments related to
  # a specific user should be destroyed if the
  # user is being destroyed.
  belongs_to :user, before_destroy: :destroy_all
end

That new before_destroy option would be great. It would support the same options as has_one/many’s dependent but declared from the “right side” of the dependency. It’s a shortcut to User.before_destroy used from the initializer.

One of the main issues to supporting something like this IMHO is on-demand (re-)loading of classes in development environment. I remember having issues with that but can’t remember the exact problem. I do remember this thread where I got great feedback form the community and finding the on_load Zeitwerk callback which could be useful. But I didn’t enter that rabbit hole at the time. In any case, I didn’t have the time to continue on that path and using the initializer solved the problem.

To be clear, I’m not against keeping has_one/many and their dependent option around. Those are fine for same-pack models.

…did you observe any impact on the app boot time?

Didn’t measure it. But didn’t feel a difference.

Thank you for the feedback!

1 Like