-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
✨ New feature: Adding our platform MoEngage as an amp-analytics plugin. #27222
Conversation
nawazMoEngage
commented
Mar 13, 2020
- I2I reference: I2I: adding amp-analytics for MoEngage #27221
- Implemented amp-analytics for the vendor MoEngage.
- Docs for the client to use this plugin: https://docs.moengage.com/docs/amp-event-analytics
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
@@ -0,0 +1,59 @@ | |||
/** | |||
* Copyright 2019 The AMP HTML Authors. All Rights Reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: 2020
Hi @nawazMoEngage, thanks for your integration. Just a few nits before we can merge. Thanks! |
"addDevice": "https://websdk.moengage.com/v2/device/add?os=_os_&app_id=!appId&sdk_ver=_sdk_ver_&app_ver=_app_ver_&device_tz_offset=_device_tz_offset_&device_tz=_device_tz_&os_platform=_os_platform_&unique_id=_unique_id_&isAmp=true", | ||
"event": "https://websdk.moengage.com/v2/report/add?os=_os_&app_id=!appId&sdk_ver=_sdk_ver_&app_ver=_app_ver_&device_tz_offset=_device_tz_offset_&device_tz=_device_tz_&os_platform=_os_platform_&unique_id=_unique_id_" | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please review these corrections to ensure they're formatted the way you want and let me know if you have any questions. Note: the extraUrlParams
that are objects get resolved to [object Object] in these tests, but since you have useBody
, they will not resolve this way when the requests are actually sent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@micajuine-ho why it is resolving to the url params? Since I am using useBody
and xhrpost
, extraUrlParams
should go in the request body.
If that is not the case, then how can I have objects in extraUrlParams
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will go in the request body in the actual request. What's happening here is that our testing framework doesn't account for this scenario right now, and so it always appends the extraUrlParams
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying. What will you suggest me to do now? we are not in the situation to have this API rewritten from the backend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can fix the testing setup to account for this situation correctly, and then we can retest to make sure that it aligns with your backend endpoints.
How does that sound?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds great. Thanks a lot..
Hope it will not take much time. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@micajuine-ho Hi Micajuine, any update on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, no updates as of yet. We've had other items of high priority to attend to recently. I will try to carve some time out this week to finish this. Thanks for the reminder.
@googlebot I signed it! |
@googlebot I signed it! |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Hi @nawazMoEngage thank you for your patience. I created a PR (#27792) that outlines possible solutions. I will update you as that PR progresses. |
@nawazMoEngage I think you should just fix your requests right now to satisfy the current tests (there's a chance that we don't end up fixing the tests because other vendors are currently working around it as well). If we do end up changing the tests, I can update the requests. You would need to change the requests in
|
OK done.. |
Can we please remove moengage.js from the code base. It's no longer required. |