posthog tracking for subscription created event#6
Conversation
Summary by CodeRabbit
WalkthroughThis PR adds a SubscriptionsContext for managing subscriptions state, a new CreateSubscriptionModal for creating subscriptions, updates the home and subscriptions tabs to use this context with search/filtering, extends icon resolution with brand keyword matching, adds a wallet-icon fallback style to SubscriptionCard, and refines PostHog analytics capture for sign-up, sign-in/sign-out transitions, and subscription creation. ChangesSubscriptions feature and analytics
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant CreateSubscriptionModal
participant PostHog
participant SubscriptionsContext
participant IndexTab
User->>CreateSubscriptionModal: open modal, fill form, submit
CreateSubscriptionModal->>CreateSubscriptionModal: validate name and price
CreateSubscriptionModal->>PostHog: capture("subscription_created")
CreateSubscriptionModal->>SubscriptionsContext: onCreate(subscription)
SubscriptionsContext->>SubscriptionsContext: addSubscription prepends new item
SubscriptionsContext-->>IndexTab: updated subscriptions list
IndexTab-->>User: renders updated FlatList
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/(auth)/sign-up.tsx (1)
46-56: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winMove
user_signed_upafterfinalize()succeeds.posthog.capture("user_signed_up")runs beforesignUp.finalize(), so a failed or aborted finalize can still emit a success event. PostHog merges anonymous events onidentify(), so attribution here isn’t the issue.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/`(auth)/sign-up.tsx around lines 46 - 56, Move the PostHog success event so it only fires after signUp.finalize() completes successfully. In sign-up.tsx, update the signUp.status === "complete" flow to await finalize first, then call posthog.capture("user_signed_up") only on success; keep the existing navigation logic inside the finalize navigate callback and avoid emitting the event before finalize can fail or abort.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@context/SubscriptionsContext.tsx`:
- Around line 20-42: `SubscriptionsProvider` currently keeps `subscriptions`
only in `useState`, so added items disappear after reload. Update the provider
to persist and hydrate the list (for example by loading/saving through
AsyncStorage) inside `SubscriptionsProvider`, `useMemo`, and `addSubscription`,
so the initial state is restored on mount and every update is written back. If
persistence is intentionally out of scope, make sure that is explicitly handled
elsewhere in the stack; otherwise wire it in here.
---
Outside diff comments:
In `@app/`(auth)/sign-up.tsx:
- Around line 46-56: Move the PostHog success event so it only fires after
signUp.finalize() completes successfully. In sign-up.tsx, update the
signUp.status === "complete" flow to await finalize first, then call
posthog.capture("user_signed_up") only on success; keep the existing navigation
logic inside the finalize navigate callback and avoid emitting the event before
finalize can fail or abort.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 91b41152-9350-4f4d-97fb-5bfff750f71a
📒 Files selected for processing (9)
app/(auth)/sign-up.tsxapp/(tabs)/index.tsxapp/(tabs)/subscriptions.tsxapp/_layout.tsxcomponents/CreateSubscriptionModal.tsxcomponents/SubscriptionCard.tsxconstants/icons.tscontext/SubscriptionsContext.tsxtype.d.ts
| export const SubscriptionsProvider = ({ | ||
| children, | ||
| }: { | ||
| children: ReactNode; | ||
| }) => { | ||
| const [subscriptions, setSubscriptions] = | ||
| useState<Subscription[]>(HOME_SUBSCRIPTIONS); | ||
|
|
||
| const addSubscription = useCallback((subscription: Subscription) => { | ||
| setSubscriptions((current) => [subscription, ...current]); | ||
| }, []); | ||
|
|
||
| const value = useMemo( | ||
| () => ({ subscriptions, addSubscription }), | ||
| [subscriptions, addSubscription], | ||
| ); | ||
|
|
||
| return ( | ||
| <SubscriptionsContext.Provider value={value}> | ||
| {children} | ||
| </SubscriptionsContext.Provider> | ||
| ); | ||
| }; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Subscriptions are lost on reload — no persistence.
SubscriptionsProvider only holds state in memory via useState. Since this PR is what actually enables users to create subscriptions (previously all data was static demo content), any subscription a user adds disappears on app restart/reload. For a subscription-tracker app this materially undermines the value of the new feature.
Consider persisting subscriptions (e.g., AsyncStorage) with hydration on mount, or confirm this is explicitly deferred to a later PR in the stack.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@context/SubscriptionsContext.tsx` around lines 20 - 42,
`SubscriptionsProvider` currently keeps `subscriptions` only in `useState`, so
added items disappear after reload. Update the provider to persist and hydrate
the list (for example by loading/saving through AsyncStorage) inside
`SubscriptionsProvider`, `useMemo`, and `addSubscription`, so the initial state
is restored on mount and every update is written back. If persistence is
intentionally out of scope, make sure that is explicitly handled elsewhere in
the stack; otherwise wire it in here.
No description provided.