Skip to content

🚀 Move timezoneCode macro from url-replacement-impl #25597

Closed
micajuine-ho wants to merge 13 commits intoampproject:masterfrom
micajuine-ho:move_timezonecode
Closed

🚀 Move timezoneCode macro from url-replacement-impl #25597
micajuine-ho wants to merge 13 commits intoampproject:masterfrom
micajuine-ho:move_timezonecode

Conversation

@micajuine-ho
Copy link
Copy Markdown
Contributor

@micajuine-ho micajuine-ho commented Nov 14, 2019

Project Tracker: #26091

Moving timezoneCode macro to amp-analytics.

Copy link
Copy Markdown
Contributor

@zhouyx zhouyx left a comment

Choose a reason for hiding this comment

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

You should also be able to remove the variable from the a4a-variable-source.js allowed list.

}
return val;
// amp-analytics variable
switch (name) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why we need to handle the variable specially?

Copy link
Copy Markdown
Contributor Author

@micajuine-ho micajuine-ho Jan 3, 2020

Choose a reason for hiding this comment

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

In the test, it expands the variables out so ${timezoneCode} -> America%2FLos_Angeles instead of _timezone_code_.

So need to whitelist them here.

Other option would be to change everyone's vendor configs, but that wouldn't work, unless we faked all of these variables' expansions (i.e. faking ${timezoneCode} -> America%2FLos_Angeles, no matter where you're testing from).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Feels like we should start to mock those variables from getMacros() just like variables from the global list now.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Sounds like the right approach. Will do that first.

@micajuine-ho
Copy link
Copy Markdown
Contributor Author

@zhouyx should we also remove them them from sandbox-vars-whitelist.js?

@zhouyx
Copy link
Copy Markdown
Contributor

zhouyx commented Jan 6, 2020

i looked at the implementation, the SANDBOX_AVAILABLE_VARS would still be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants