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

Google Analytics settings for SendGridAdapter #462

Merged

Conversation

tomtaylor
Copy link
Contributor

Added the ability to enable/disable Google Analytics settings for an individual email in SendGrid.

Added the ability to enable/disable Google Analytics settings for an
individual email in SendGrid.
|> with_google_analytics(false)
"""
def with_google_analytics(email, enabled, utm_params \\ %{})
def with_google_analytics(email, enabled, utm_params) when is_boolean(enabled) and is_map(utm_params) do
Copy link
Contributor

Choose a reason for hiding this comment

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

What would you think about adding a couple of unit tests for this function that verify for example the right types being passed in and that UTM params not in white list would get filtered out?

Copy link
Contributor

@maymillerricci maymillerricci left a comment

Choose a reason for hiding this comment

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

Looks great! Just one question about additional tests. Thanks for your work on this!

@tomtaylor
Copy link
Contributor Author

@maymillerricci all done! I also added the ability to set the UTM params using a Keyword list, since it seemed like the flexibility would be helpful.

@@ -149,4 +149,59 @@ defmodule Bamboo.SendGridHelperTest do
email |> with_bypass_list_management(1)
end
end

test "with_google_analytics/2 with Map utm_params", %{email: email} do
Copy link
Contributor

@maymillerricci maymillerricci Mar 18, 2019

Choose a reason for hiding this comment

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

Should these be with_google_analytics/3?

@maymillerricci
Copy link
Contributor

Thanks @tomtaylor! Although the flexibility for being able to pass in the params as a map or keyword list might be nice, I wonder in general whether for simplicity on this end, we might want to restrict it to only pass them as a map, and then people on their end can update what's being passed in into a map? I think in most places here similar params are expected to be maps. What do you think? Do you think it's important to have the flexibility of being able to also pass in a keyword list?

@tomtaylor
Copy link
Contributor Author

If there's precedent for just accepting Maps, that make sense. The flexibility isn't a major issue here. Will update the test descriptions when I get a moment!

Based on feedback from @maymillerricci, drop the ability to accept Keywords.
@tomtaylor
Copy link
Contributor Author

@maymillerricci I think this is ready to go.

|> with_google_analytics(true, %{utm_source: "email", utm_campaign: "campaign"})

email
|> with_google_analytics(true, utm_source: "email", utm_campaign: "campaign")
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for updating this!! Does this example now need be removed?

end

def with_google_analytics(_email, _enabled, _utm_params) do
raise "expected with_google_analytics enabled parameters to be a boolean"
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
raise "expected with_google_analytics enabled parameters to be a boolean"
raise "expected with_google_analytics enabled parameter to be a boolean"

@tomtaylor
Copy link
Contributor Author

Good spot! Fixed.

@maymillerricci maymillerricci merged commit 3f79b73 into beam-community:master Jul 19, 2019
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.

2 participants