feat!: Implement before_interceptor that runs before stripping the recipients with the formatter

[tarzan]

I would like to use the interceptor to detect the preferences of the rich struct that is set as a receiver on the 'to:'

The (implemented) formatter strips all info from this struct and just set a {name, email} tuple instead which I cannot use at the interceptor level anymore.

I decided to swap them: interceptor first normalization and validation second - can't think of a reason this would result in unwanted behavior.

Could you take this under consideration?

[doomspork]

Thank you @tarzan! I looked this over and left a quick comment on the test changes.

While I can't immediately think of a negative impact here, I do suspect this could have unintended consequences to current users of Bamboo and would require a breaking changes. If so, that would warrant some more conversation 🤔

[doomspork]

Hi @tarzan can you walk me through this part of the change? It's not immediately clear why we made these changes other than to use multi-function heads instead of the prior solution.

[tarzan]

Of course. Previously this interceptor (created for test scenario's) would expect the to: field to be populated by a list of tuples: {name, email}.
The actual test scenario's just put strings containing the email(s) on the to: field, so I had to check for a single binary that is an email or a list of binaries.

[tarzan]

Thank you @tarzan! I looked this over and left a quick comment on the test changes.

While I can't immediately think of a negative impact here, I do suspect this could have unintended consequences to current users of Bamboo and would require a breaking changes. If so, that would warrant some more conversation 🤔

You are absolutely right, this is a breaking change. Any custom interceptors might expect a tuple [{name, email}] as the value of to: in the Bamboo.Email struct. With this change it will now contain the value that was actually set during the construction of the Bamboo.Email before formatting takes place.

In our case the value on to: is a %User{} struct that holds values of a user in our app, one of its fields is some preferences on whether the user would want to receive certain emails. Setting this fully populated User struct as the receiver of the email allows us to abstract checking of preferences to an Interceptor - which I think is conceptually the goal of an interceptor.

I can totally understand that current users that have spend time in constructing their own interceptors would not be to thrilled about this change. Would it help if I wrote some simple instructings on what to look for and how to apply these changes - ie something like a (mini) migration guide?

[tarzan]

hey @doomspork any updates on how you would propose we move forward with this? or would like to keep it on hold?

[tarzan]

still waiting for approval here, @doomspork is there anything I can do to make things easier?

[doomspork]

Hi @tarzan sorry I've been swamped with my new role. I've been able to recruit another maintainer to help @yordis and myself with keeping up with these repos since we're spread pretty thin.

I think in a perfect world we'd like to avoid a breaking change so soon after taking over the repo but I'm not sure it's avoidable here 🤔 @joeljuca do you have any thoughts or concerns?

[doomspork]

@tarzan thinking about this some more: Do you think we have an opportunity here to have pre- and post- interceptors, allowing us to avoid a breaking change? 🤔 We keep interceptors as the post validate_and_normalize and add before_ validate_and_normalize interceptors.

What do you think?

We're very short on contributors/maintainers and having to support a breaking change (and previous versions) is a pretty significant burden at this time so I'd really love to find a way to avoid supporting concurrent versions whenever possible.

cc @joeljuca @samuelpordeus @btkostner for comment/thoughts

[github-actions]

This pull request has been automatically marked as "stale:discard". If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated!.

[tarzan]

@tarzan thinking about this some more: Do you think we have an opportunity here to have pre- and post- interceptors, allowing us to avoid a breaking change? 🤔 We keep interceptors as the post validate_and_normalize and add before_ validate_and_normalize interceptors.

What do you think?

We're very short on contributors/maintainers and having to support a breaking change (and previous versions) is a pretty significant burden at this time so I'd really love to find a way to avoid supporting concurrent versions whenever possible.

cc @joeljuca @samuelpordeus @btkostner for comment/thoughts

So I refactored the code to introduce a :before_interceptor so this won't be a breaking change anymore. Think you can now safely merge the addition.

While I understand the reasoning, I think having the interceptor after the formatter is a design mistake and it should've been implemented as before formatting. Maybe consider adding a deprecation warning on the :interceptor config and migrate to the before_interceptor on a major version bump?

[tarzan]

rebased. Anyone available for reviewing this?

[tarzan]

up?

[tarzan]

We're closing in on a year for this one. @doomspork this doesn't bring any breaking changes anymore and should be safe to merge, could you please review one more time?