fix: Autocapture native app lifecycle events #398
Conversation
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR Summary
This PR unifies and fixes the behavior of lifecycle event tracking in the React Native SDK, ensuring consistent behavior between different configuration methods.
- Modified
useLifecycleTracker.tsto capture initial URL withApplication Openedevent - Consolidated lifecycle tracking configuration in
PostHogProvider.tsxby usingautocapture.captureLifecycleEventsas source of truth - Updated
captureNativeAppLifecycleEventsoption to match behavior withautocapture.captureLifecycleEvents - Added proper cleanup for AppState subscription in lifecycle tracker
3 file(s) reviewed, 3 comment(s)
Edit PR Review Bot Settings | Greptile
rafaeelaudibert
force-pushed
the
fix-native-lifecycle-events-not-being-tracked-on-autocapture
branch
from
3eadc32 to
57c4910
Compare
|
Size Change: -392 B (-0.3%) Total Size: 131 kB
ℹ️ View Unchanged
|
Right now, we have two configurations for autotracking lifecycle events, and we suggest customers to only use one or another. The problem is that they're not equivalent.
The `options.captureNativeAppLifecycleEvents` option is capturing both app lifecycle events ("Application Opened", "Application Backgrounded", "Application Became Active") but also native events ("Application Installed" and "Application Updated").
`autocapture.captureLifecycleEvents` on the other hand does not capture the latter.
Let's make them act in the same way by using the option from inside `autocapture` - the one we suggest in our docs - and copying it over to the `options` config hash. They'll now behave in the same way, there isn't even a problem setting them both at the same time - we might need to update docs.
See https://posthoghelp.zendesk.com/agent/tickets/25578
rafaeelaudibert
force-pushed
the
fix-native-lifecycle-events-not-being-tracked-on-autocapture
branch
from
57c4910 to
735e93d
Compare
|
One issue I see is that after this PR, you cannot opt out of the app install and app update events. |
Yeah, 100% true. In my mind, the best solution is to break the existing API compatibility with a major and then split this setting up in two at the config level rather than having some of it running at the provider level like we have now. One problem we have now is that you can't opt in to native lifecycle events without opting in to lifecycle events, so it's already kinds restrictive anyway. So, we have two options: get a new major ready now, and we might wanna include more things in it, or just keep this as is and I can tell the user to move from the |
tbh I think this was just an oversight, the wording 'native' lifecycles does not even reflect anything 'native' just because it captures 2 more possible events. |
|
@rafaeelaudibert #401 I think the reason why 'native' and not 'native' is because 'native' might have the storage set up and can compare the versions (if its a new install or an update) and not native there's no storage at all (which is not true since you can set up your own storage function/its just not automatic), so it's confusing but I guess we'd be fine with a minor after merging my PR. if one does not want the new approach with app install and app update events, they can simply set up their own WDYT? |
Ok, I like that, especially the fact that they can just roll their own if they want a more customizable experience. Then the next major can add specific configs for each individual kind of event - or add something akin to Just to confirm: Are you proposing we just merge your PR on this one, and then both go live as a minor? I'm happy to do that On another note, I don't know how releases work on this repo, and I couldn't find any info in the README - it's too barebones IMO. |
yes, the release is simple, all info is here |
|
@marandaneto Just merged your branch here, will get the release ready - by EOD, I'm working on some other stuff already |
marandaneto
deleted the
fix-native-lifecycle-events-not-being-tracked-on-autocapture
branch
Problem
Right now, we have two configurations for autotracking lifecycle events, and we suggest customers to only use one or another. The problem is that they're not equivalent.
The
options.captureNativeAppLifecycleEventsoption is capturing both app lifecycle events ("Application Opened", "Application Backgrounded", "Application Became Active") but also native events ("Application Installed" and "Application Updated").autocapture.captureLifecycleEventson the other hand does not capture the latter.Changes
Let's make them act in the same way by using the option from inside
autocapture- the one we suggest in our docs - and copying it over to theoptionsconfig hash. They'll now behave in the same way, there isn't even a problem setting them both at the same time - we might need to update docs.See https://posthoghelp.zendesk.com/agent/tickets/25578
Release info Sub-libraries affected
Bump level
Libraries affected
Changelog notes
fix: Autocapture native app lifecycle events