Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to deliver_now to return adapter response #466

Merged
merged 4 commits into from
Apr 12, 2019

Conversation

maymillerricci
Copy link
Contributor

As an alternative to #452, to resolve #451 and #161, this adds a response: true option to deliver_now that returns a tuple of the response from the adapter's deliver call and the Email struct. This is a non-breaking change, since without the response: true option everything will work as usual, and the Email will be returned, but this adds the option to pass that additional argument in and also get the response back.

Copy link
Contributor

@lancejjohnson lancejjohnson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maymillerricci This looks great! Seeing this implemented, I think, bolsters the case for an approach like this over adding to the email struct. Thanks for doing this. I just have one question for discussion but other than that 👍

else
debug_sent(email, adapter)
response = adapter.deliver(email, config)
{response, email}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did you decide to order the tuple response first then email? At first glance I think I may have expected the order reversed. That's not to suggest that you should reverse the order; I just thought it would be interesting to talk through.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question! I initially decided to do {response, email} since I was thinking of the typical {:ok, thing} / {:error, thing} pattern and was thinking of :ok and :error as a response, so the response here would match that and come first. But now that I think about it more, it's different since it's more than just an atom with like a response status, and it comes after the sending of the email, so it probably makes more sense to come second. Plus, since this is an addition to the existing function which just returns an email, it also probably makes sense for the extra information to come after the expected information. I think I will probably reverse it. Thanks!

@maymillerricci maymillerricci force-pushed the mmr-response-option branch 3 times, most recently from 8b963ed to 3a98e50 Compare April 1, 2019 21:21
@maymillerricci
Copy link
Contributor Author

I reversed the tuple to be {email, response} in 3a98e50.

@lancejjohnson
Copy link
Contributor

@maymillerricci LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Response values from adapter (deliver_now) behavior
2 participants