feat(onboarding): mobile web welcome flow with email signup#2624
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 35 minutes and 0 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR adds a mobile-web specific onboarding flow for touch-based devices. It introduces new UI components (MobileWebWelcome and MobileWebSignupSent), updates the main onboarding entry point to conditionally route unauthenticated mobile-web users to this flow, implements email validation and sending, and adds backend support with database persistence and email template updates. Changes
Possibly related PRs
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@js/app/packages/app/component/interactive-onboarding/InteractiveOnboarding.tsx`:
- Around line 65-71: The current error handling in InteractiveOnboarding.tsx
inspects the raw message string (const msg = result[0]?.[0]?.message) for
substrings '429' and '400', which misses structured responses; instead, read the
HTTP status from the client result (e.g., result[0]?.[0]?.status or
result[0]?.status) and branch on that, falling back to checking normalized
server message values like 'rate limit exceeded' or 'invalid email' when status
is unavailable, then call toast.failure(...) accordingly so the rate-limit and
invalid-email toasts are shown reliably.
- Around line 400-403: The analytics.track call that sets source based on params
currently uses params.has('mobile_welcome_email') which treats any presence
(including false or empty) as true; update the logic in the
InteractiveOnboarding component where analytics.track('onboarding_start', ...)
is called to check the actual parameter value by using
params.get('mobile_welcome_email') === 'true' (instead of params.has(...)) so
the source is set only when the query value equals the string 'true'.
- Line 56: Component calls authServiceClient.sendMobileWelcomeEmail directly;
move this into a TanStack Query mutation in the queries package and call that
from the component. Add a new mutation (e.g., export useSendMobileWelcomeEmail)
in queries/auth that uses useMutation and calls
authServiceClient.sendMobileWelcomeEmail(email), export the mutation hook and
any needed types, then update InteractiveOnboarding.tsx to import and use
useSendMobileWelcomeEmail (calling mutate or mutateAsync) instead of calling
authServiceClient.sendMobileWelcomeEmail directly; preserve existing
success/error handling and loading state.
In `@js/app/packages/app/component/interactive-onboarding/MobileWebWelcome.tsx`:
- Around line 59-65: The email input in the MobileWebWelcome component lacks an
explicit accessible name; add one by either wrapping the input with a <label>
tied to the input via an id or by adding an aria-label/aria-labelledby attribute
to the input element (the input using value={email()} and onInput={(e) =>
setEmail(e.currentTarget.value)}). Ensure the id on the input matches the
label's htmlFor if using a label, or provide a clear descriptive aria-label like
"Email address" so screen readers announce the field.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7bbef4d1-2480-4b86-9c66-4df1bf103e67
⛔ Files ignored due to path filters (3)
js/app/packages/service-clients/service-auth/generated/client.tsis excluded by!**/generated/**js/app/packages/service-clients/service-auth/generated/schemas/index.tsis excluded by!**/generated/**js/app/packages/service-clients/service-auth/generated/schemas/sendMobileWelcomeEmailResponse.tsis excluded by!**/generated/**
📒 Files selected for processing (9)
js/app/packages/app/component/interactive-onboarding/InteractiveOnboarding.tsxjs/app/packages/app/component/interactive-onboarding/MobileWebSignupSent.tsxjs/app/packages/app/component/interactive-onboarding/MobileWebWelcome.tsxjs/app/packages/app/lib/analytics/app-events.tsjs/app/packages/service-clients/service-auth/client.tsjs/app/packages/service-clients/service-auth/openapi.jsonrust/cloud-storage/authentication_service/src/api/mobile_welcome_email/_welcome_email_template.htmlrust/cloud-storage/authentication_service/src/api/mobile_welcome_email/mod.rsrust/cloud-storage/authentication_service/src/api/swagger.rs
Summary
/app/welcomefor unauthenticated touch-device users, with an email signup form that sends a branded welcome email via SESmacro.com/app/welcome?mobile_welcome_email=trueso desktop landings from the email are tracked in PostHog (onboarding_startwithsource: 'mobile_welcome_email'){ sent: bool }to distinguish first send from duplicate, frontend shows toast for already-sent / rate-limited / invalid casesmobile_web_welcome_viewed,onboarding_step_welcome, andmobile_web_signup_sent_viewedanalytics events through the mobile flow