feat(setup): /setup onboarding pages for the welcome-email links (chat#1885) - #1888
Conversation
…(chat#1885) The welcome email (api#774) deep-links six /setup routes that did not exist. Add them by reusing existing onboarding components (DRY): - /setup -> redirect to /setup/artists (the 'Confirm your roster' CTA) - /setup/artists -> RosterSocialsFlow (roster step) - /setup/socials -> RosterSocialsFlow initialStep='socials' (deep link) - /setup/tasks -> FirstTaskStep - /setup/catalog -> redirect /catalogs (no dedicated claim step yet) - /setup/valuation -> redirect /catalogs (baseline valuation = catalog report) RosterSocialsFlow gains an optional initialStep prop (defaults to 'roster', so existing /onboarding/roster is unchanged) so /setup/socials can open at socials. tsc + lint clean on touched files. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughAdds Next.js setup routes for artists, socials, tasks, catalog, and valuation. The setup root redirects to artists, while ChangesSetup onboarding flow
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Browser
participant SetupPage
participant SetupArtistsPage
participant RosterSocialsFlow
Browser->>SetupPage: Open /setup
SetupPage-->>Browser: Redirect to /setup/artists
Browser->>SetupArtistsPage: Open /setup/artists
SetupArtistsPage->>RosterSocialsFlow: Render with roster as initial step
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6ba18c3925
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| }: { | ||
| initialStep?: "roster" | "socials"; | ||
| } = {}) => { | ||
| const [step, setStep] = useState<FlowStep>(initialStep); |
There was a problem hiding this comment.
When /setup/socials passes initialStep="socials", the flow bypasses ConfirmRosterStep's loading and empty-roster guard. On a cold authenticated load, or while Privy/user data is still resolving, useArtistsRoster returns sorted=[] with isPending true, but VerifySocialsStep renders an enabled “Looks good” button, so users can advance to “Roster verified” before any artist/social cards are shown. Gate the social step until the roster query has resolved, or fall back to the roster step when there are no artists.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
components/Onboarding/RosterSocialsFlow.tsx (1)
20-25: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winExport a named props interface for the component API.
The new public prop is declared as an inline anonymous type. Extracting
RosterSocialsFlowPropsmakes the API discoverable and easier to extend while satisfying the repository’s TypeScript component conventions.As per coding guidelines: “Export component prop types with explicit
ComponentNamePropsnaming convention.” As per path instructions: “Use TypeScript interfaces for props.”Proposed refactor
+export interface RosterSocialsFlowProps { + initialStep?: "roster" | "socials"; +} + const RosterSocialsFlow = ({ initialStep = "roster", -}: { - initialStep?: "roster" | "socials"; -} = {}) => { +}: RosterSocialsFlowProps) => {🤖 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 `@components/Onboarding/RosterSocialsFlow.tsx` around lines 20 - 25, Extract the inline props type from RosterSocialsFlow into an exported TypeScript interface named RosterSocialsFlowProps, retaining the optional initialStep union and the existing default behavior. Update the component signature to use this interface.Sources: Coding guidelines, Path instructions
🤖 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.
Nitpick comments:
In `@components/Onboarding/RosterSocialsFlow.tsx`:
- Around line 20-25: Extract the inline props type from RosterSocialsFlow into
an exported TypeScript interface named RosterSocialsFlowProps, retaining the
optional initialStep union and the existing default behavior. Update the
component signature to use this interface.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: e2366cea-0879-4175-8df4-2128b95cb84a
📒 Files selected for processing (7)
app/setup/artists/page.tsxapp/setup/catalog/page.tsxapp/setup/page.tsxapp/setup/socials/page.tsxapp/setup/tasks/page.tsxapp/setup/valuation/page.tsxcomponents/Onboarding/RosterSocialsFlow.tsx
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 issues found across 7 files
Confidence score: 3/5
- In
components/Onboarding/RosterSocialsFlow.tsx, starting withinitialStep="socials"can skip the roster step’s loading/empty-roster guards on cold load, so users may enter the socials step before roster data is ready and hit a broken or inconsistent onboarding path — enforce the same roster readiness checks before allowing the socials step. - In
app/setup/valuation/page.tsx, the valuation deep link currently lands on the catalog list instead of a baseline valuation, which adds friction and can block valuation entirely when the list is empty — resolve/select a catalog ID before navigation (or provide a fallback) so the deep link always reaches a valuation flow.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="app/setup/valuation/page.tsx">
<violation number="1" location="app/setup/valuation/page.tsx:10">
P2: The valuation deep link lands on the catalog list rather than the baseline valuation, so users must discover and select a catalog—and cannot reach a valuation at all when the list is empty. Resolving a catalog ID before redirecting to `/catalogs/[catalogId]`, or providing a dedicated selection/valuation landing page, would make this onboarding link fulfill its stated step.</violation>
</file>
<file name="components/Onboarding/RosterSocialsFlow.tsx">
<violation number="1" location="components/Onboarding/RosterSocialsFlow.tsx:25">
P2: When `initialStep="socials"` is passed (via `/setup/socials`), the flow initializes directly at the socials step, bypassing the roster step's loading and empty-roster guards. On a cold load—while `useArtistsRoster` is still resolving (`isPending: true`, `sorted: []`)—the `VerifySocialsStep` can render with an enabled "Looks good" button, allowing users to advance past verification before any artist/social cards have loaded.
Consider gating the socials step on the roster query having resolved with at least one artist, falling back to the roster step otherwise. For example, you could check `isPending` or an empty roster and override `initialStep` to `"roster"` until the data is ready.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| * Revisit if a dedicated valuation landing is built. | ||
| */ | ||
| export default function SetupValuationPage() { | ||
| redirect("/catalogs"); |
There was a problem hiding this comment.
P2: The valuation deep link lands on the catalog list rather than the baseline valuation, so users must discover and select a catalog—and cannot reach a valuation at all when the list is empty. Resolving a catalog ID before redirecting to /catalogs/[catalogId], or providing a dedicated selection/valuation landing page, would make this onboarding link fulfill its stated step.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/setup/valuation/page.tsx, line 10:
<comment>The valuation deep link lands on the catalog list rather than the baseline valuation, so users must discover and select a catalog—and cannot reach a valuation at all when the list is empty. Resolving a catalog ID before redirecting to `/catalogs/[catalogId]`, or providing a dedicated selection/valuation landing page, would make this onboarding link fulfill its stated step.</comment>
<file context>
@@ -0,0 +1,11 @@
+ * Revisit if a dedicated valuation landing is built.
+ */
+export default function SetupValuationPage() {
+ redirect("/catalogs");
+}
</file context>
| }: { | ||
| initialStep?: "roster" | "socials"; | ||
| } = {}) => { | ||
| const [step, setStep] = useState<FlowStep>(initialStep); |
There was a problem hiding this comment.
P2: When initialStep="socials" is passed (via /setup/socials), the flow initializes directly at the socials step, bypassing the roster step's loading and empty-roster guards. On a cold load—while useArtistsRoster is still resolving (isPending: true, sorted: [])—the VerifySocialsStep can render with an enabled "Looks good" button, allowing users to advance past verification before any artist/social cards have loaded.
Consider gating the socials step on the roster query having resolved with at least one artist, falling back to the roster step otherwise. For example, you could check isPending or an empty roster and override initialStep to "roster" until the data is ready.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At components/Onboarding/RosterSocialsFlow.tsx, line 25:
<comment>When `initialStep="socials"` is passed (via `/setup/socials`), the flow initializes directly at the socials step, bypassing the roster step's loading and empty-roster guards. On a cold load—while `useArtistsRoster` is still resolving (`isPending: true`, `sorted: []`)—the `VerifySocialsStep` can render with an enabled "Looks good" button, allowing users to advance past verification before any artist/social cards have loaded.
Consider gating the socials step on the roster query having resolved with at least one artist, falling back to the roster step otherwise. For example, you could check `isPending` or an empty roster and override `initialStep` to `"roster"` until the data is ready.</comment>
<file context>
@@ -12,9 +12,17 @@ type FlowStep = "roster" | "socials" | "done";
+}: {
+ initialStep?: "roster" | "socials";
+} = {}) => {
+ const [step, setStep] = useState<FlowStep>(initialStep);
return (
</file context>
Preview verification (authed,
|
1 participant
Adds the
/setup/*onboarding routes that the redesigned welcome email (api#774) deep-links. Those routes don't exist yet (app/setupwas absent), so every link in the email would 404 in production. Part of chat#1885.What this adds
Six thin pages, built by reusing existing onboarding components (no new UI, no duplicated scaffolding):
/setup/setup/artists/setup/artistsRosterSocialsFlow(roster step)/setup/socialsRosterSocialsFlowopened at the socials step/setup/catalog/catalogs/setup/valuation/catalogs/setup/tasksFirstTaskStepPages inherit all providers/chrome from the root
app/layout.tsx(no per-route layout, and there's no auth wall to add — Privy auto-login is soft).Only code change beyond the pages
RosterSocialsFlowgains an optionalinitialStepprop (defaults to"roster", so the existing/onboarding/rostermount is unchanged) so/setup/socialscan open directly at the socials step. This reuses the existing roster→socials→verified flow rather than re-mounting the granular steps with duplicated container/nav.Decisions to confirm (the two "gaps")
There is no dedicated component today for two steps, so I chose the pragmatic redirect:
/setup/catalog→/catalogs— the onboardingcatalogcheckpoint itself just links to/catalogs; there's no claim-catalog step component./setup/valuation→/catalogs— the baseline valuation is the catalog report (/catalogs/[catalogId]), which isn't addressable without a catalog id from a generic email, so it routes to the catalog list.If you'd prefer dedicated pages (or different targets) for either, say so and I'll build them.
/setupbehavior/setupredirects to/setup/artistsso the "Confirm your roster" CTA lands on the interactive roster step. (An alternative was mountingOnboardingSequenceas a progress hub, but its step cards link to the legacy/artists//catalogs//taskspages, which would be inconsistent with these interactive/setup/*deep links — happy to switch if you want the hub instead.)Coordinates with chat#1887
That PR converges the onboarding surfaces / retires the interim
/onboarding/*mounts. These/setup/*routes should become the converged home for these steps rather than a third parallel surface — flagging so they're reconciled.Verification
tsc --noEmit+eslintclean on all touched files.pnpm build+ preview screenshots: pending CI / preview (will add authed screenshots of each/setup/*page).🤖 Generated with Claude Code
Summary by cubic
Add
/setup/*onboarding routes for the redesigned welcome email links to prevent 404s and reuse existing onboarding components. Supports chat#1885 and the welcome email in api#774.Written for commit 6ba18c3. Summary will update on new commits.