fix(deeplinks): get url from the correct field for CT events #6356
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MuckT
approved these changes
Dec 12, 2024
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6356 +/- ##
==========================================
+ Coverage 88.92% 88.97% +0.05%
==========================================
Files 735 735
Lines 31366 31402 +36
Branches 5821 5832 +11
==========================================
+ Hits 27892 27940 +48
+ Misses 3276 3266 -10
+ Partials 198 196 -2
... and 2 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
MuckT
pushed a commit
that referenced
this pull request
Dec 17, 2024
### Description Per this [update](https://github.com/CleverTap/clevertap-react-native/blob/2c2ab9664b9e83cde936d14b511896d7edd5ecdc/docs/callbackPayloadFormat.md?plain=1#L12) in clever tap docs, this likely slipped through on a clevertap package upgrade ### Test plan Can't easily test CT push notifications with a dev build, but this has been working on Android, where the url was extracted correctly, and also confirmed with logging on iOS that the deeplink field is present at the top level of the event. Also tested the 2 callbacks being called scenario by updating the code to call handleOpenUrl twice (one with isSecureOrigin: false and the other with true) in the Linking event listener, the 2nd call mimics the call that would've been done by the CT push notification listener callback, and also introducing a delay in the saga (to mimic slow sagas, which can be killed by `takeLatest` if another event of the same action type is fired). On opening a deeplink on the browser with an openScreen deeplink and the app backgrounded, confirmed that the navigation to the correct screen happens. ### Related issues - Fixes ACT-1469 ### Backwards compatibility Yes ### Network scalability N/A
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Per this update in clever tap docs, this likely slipped through on a clevertap package upgrade
Test plan
Can't easily test CT push notifications with a dev build, but this has been working on Android, where the url was extracted correctly, and also confirmed with logging on iOS that the deeplink field is present at the top level of the event.
Also tested the 2 callbacks being called scenario by updating the code to call handleOpenUrl twice (one with isSecureOrigin: false and the other with true) in the Linking event listener, the 2nd call mimics the call that would've been done by the CT push notification listener callback, and also introducing a delay in the saga (to mimic slow sagas, which can be killed by
takeLatestif another event of the same action type is fired). On opening a deeplink on the browser with an openScreen deeplink and the app backgrounded, confirmed that the navigation to the correct screen happens.Related issues
Backwards compatibility
Yes
Network scalability
N/A