Demo the 1.0.1 lifecycle events - #44
Conversation
SDK 1.0.1 ships the Segment lifecycle set (sdk-react-native #69/#70/#71), so the example can finally exercise it. Bumped to ^1.0.1 and added a Lifecycle Events card covering the parts that CANNOT be autocaptured: push delivery is invisible to JavaScript without a native module, and a crash needs a crash. - Push Notification Received / Tapped / Bounced via the new explicit methods, with a note that in a real app these calls live in the push handler rather than behind a button. - Trigger Crash, behind a confirmation, throwing asynchronously so the SDK's global handler reports Application Crashed. The redbox still appears afterwards — that is the handler chain working, not a failure. Enabled the two opt-in autocapture flags (foregrounded, crashes) so the demo actually shows them; both are documented inline with why they are opt-in. pnpm-workspace: excluded our own package from minimumReleaseAge. That guard exists to blunt supply-chain attacks on third-party deps; applying a 7-day delay to our own SDK stops an example from demonstrating a fresh release. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Dependency limit exceeded — report not shown. This pull request scan exceeded the 10,000-dependency limit applied to this scan, so the results are incomplete and may be inaccurate. To avoid reporting false positives, Socket has not posted a report. Upgrade your plan to raise the dependency limit and get complete reports, or view the partial scan in the dashboard. Socket is always free for open source. If this is a non-commercial open source project, contact us to request a free Team account. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f8ec4676a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // still see the redbox — that is the intended behaviour, not a failure. The | ||
| // event is flushed before the handler chain continues. | ||
| const handleTriggerCrash = () => { | ||
| Alert.alert( |
There was a problem hiding this comment.
Handle crash confirmation outside Alert on web
When this example is run through the web script, React Native Web's Alert.alert displays the browser alert but does not support the custom button callbacks, so the Throw handler is never invoked and the new Trigger Crash demo cannot emit Application Crashed. Use a web-specific confirmation path such as window.confirm, or a cross-platform modal whose buttons invoke the callback.
Useful? React with 👍 / 👎.
Two separate problems, both surfaced by a review comment on the Alert usage.
1. React Native Web's Alert is a no-op — literally `static alert() {}`. It
shows nothing AND never invokes the button callbacks, so anything gated
behind Alert.alert is dead code on web. Added a confirmDestructive() helper
that uses window.confirm there. Verified: the confirm now fires with the
right message.
2. Fixing that exposed the real limitation. Crash tracking cannot work on web
at all. The SDK reports Application Crashed by wrapping ErrorUtils, but on
React Native Web an uncaught error fires window.onerror and NEVER reaches
ErrorUtils — the handler is installed and nothing ever calls it. Probed
directly: async throw -> window.onerror fires, ErrorUtils does not.
So the button could never have emitted the event on web. Rather than ship one
that silently does nothing, it now says so on the card and explains why when
tapped. Unchanged on iOS and Android, where ErrorUtils is the real mechanism.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
SDK 1.0.1 ships the Segment lifecycle set (getformo/sdk-react-native#69, #70, #71), so the example can finally exercise it. Bumped to
^1.0.1and added a Lifecycle Events card.What's demoed
Application Installed / Opened / Backgrounded / ForegroundedandDeep Link Openedare autocaptured — nothing to add. The card covers the two that cannot be:Application Crashed. In development the redbox still appears afterwards; that's the handler chain working, not a failure.Both opt-in autocapture flags (
foregrounded,crashes) are enabled inconfig/formo.ts, documented inline with why they're opt-in in the first place.pnpm
Excluded our own package from
minimumReleaseAge. That guard exists to blunt supply-chain attacks on third-party deps; applying a 7-day delay to our own SDK stops the example from demonstrating a fresh release — which is the entire point of it.End-to-end verification
Ran against the published 1.0.1 on all three targets, confirming events in Tinybird each time.
app://com.formo.analytics.demo/<Screen>Application Installed/OpenedDeep Link Opened(afterApplication Opened)Application Backgrounded→ForegroundedApplication CrashedApplication Foregroundedfired on iOS only where I could drive a real background→foreground transition (simctl launch com.apple.springboard, then relaunch). The sequence was exactly as designed:Opened→Backgrounded→Opened(from_background: true) →Foregrounded.For the crash I invoked the installed handler directly rather than tapping the button — no tap driver was available for the iOS simulator, and on web a real throw risks a blocking dialog.
ErrorUtils.getGlobalHandler()(new TypeError(...), true)exercises the identical code path. The error re-raised to the previous handler (proving the chain is intact) and the event landed in Tinybird with the full payload:Not verified end-to-end: the crash and push buttons via actual taps on a device. Both are covered by unit tests in the SDK (12 for the crash handler alone, including the chain invariant).
14 tests pass, typecheck and lint clean.
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.