feat(onboarding): collapse verify-socials into per-artist panels (chat#1889 row 12)#1896
feat(onboarding): collapse verify-socials into per-artist panels (chat#1889 row 12)#1896sweetmantech wants to merge 2 commits into
Conversation
chat#1889 matrix row 9 (onboarding blocker).
useSocialFix could only add or replace a profile. A user who added the wrong
social had no way to take it back and was left with a list they could not
correct, which reads as a dead end in the middle of setup.
- New deleteArtistSocial wraps the existing
DELETE /api/artists/{id}/socials/{socialId} endpoint.
- New useSocialRemove hook mutates + refreshes the roster, mirroring
useSocialFix.
- SocialRow gains a Remove affordance beside Edit; ArtistSocialsCard and
VerifySocialsStep thread it through.
- The no-matches copy now states adding is optional and the step can be
continued without it, instead of reading like an error.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
chat#1889 matrix row 12.
Every rostered artist's socials rendered expanded at once, so a manager with a
real roster faced an unscannable wall and could not tell which artist still
needed attention.
Each artist is now a Collapsible panel whose trigger shows the name plus a
profile count ("2 profiles" / "No profiles matched"). A single-artist roster
opens by default, since there is nothing to traverse.
Uses the existing @radix-ui/react-collapsible primitive already in the project
rather than adding an accordion dependency.
Co-Authored-By: Claude Opus 5 (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.
|
|
Warning Review limit reached
Next review available in: 27 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (5)
✨ Finishing Touches🧪 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 |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 7 files
Confidence score: 4/5
- In
components/Onboarding/VerifySocialsStep.tsx, remove actions use a globalisFixing/removingSocialIdscope, so deleting one artist’s social can disable social rows for the entire roster and block unrelated edits; this can cause confusing UI lockups during onboarding — scope remove state per artist (or key by artist+social) inuseSocialRemoveand the component state wiring.
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="components/Onboarding/VerifySocialsStep.tsx">
<violation number="1" location="components/Onboarding/VerifySocialsStep.tsx:38">
P2: `isFixing` scopes per-artist for fixes but globally for removes — removing a social from one artist disables every artist's social rows across the roster. The `useSocialRemove` hook exposes only `removingSocialId` (the social being removed), not the artist it belongs to, so the condition `fixingArtistId === artist.account_id || removingSocialId !== null` cannot scope the disable per-artist during removal. This means removing a social from artist A locks the edit/remove/submit buttons on artists B, C, and D until the request finishes — an unnecessarily broad disruption that doesn't match the per-artist scope of `fixingArtistId`. Consider exposing `removingArtistId` from `useSocialRemove` (or having the parent derive it from the calling context) so the condition can be `fixingArtistId === artist.account_id || removingArtistId === artist.account_id`.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| key={artist.account_id} | ||
| artist={artist} | ||
| isFixing={fixingArtistId === artist.account_id} | ||
| isFixing={ |
There was a problem hiding this comment.
P2: isFixing scopes per-artist for fixes but globally for removes — removing a social from one artist disables every artist's social rows across the roster. The useSocialRemove hook exposes only removingSocialId (the social being removed), not the artist it belongs to, so the condition fixingArtistId === artist.account_id || removingSocialId !== null cannot scope the disable per-artist during removal. This means removing a social from artist A locks the edit/remove/submit buttons on artists B, C, and D until the request finishes — an unnecessarily broad disruption that doesn't match the per-artist scope of fixingArtistId. Consider exposing removingArtistId from useSocialRemove (or having the parent derive it from the calling context) so the condition can be fixingArtistId === artist.account_id || removingArtistId === artist.account_id.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At components/Onboarding/VerifySocialsStep.tsx, line 38:
<comment>`isFixing` scopes per-artist for fixes but globally for removes — removing a social from one artist disables every artist's social rows across the roster. The `useSocialRemove` hook exposes only `removingSocialId` (the social being removed), not the artist it belongs to, so the condition `fixingArtistId === artist.account_id || removingSocialId !== null` cannot scope the disable per-artist during removal. This means removing a social from artist A locks the edit/remove/submit buttons on artists B, C, and D until the request finishes — an unnecessarily broad disruption that doesn't match the per-artist scope of `fixingArtistId`. Consider exposing `removingArtistId` from `useSocialRemove` (or having the parent derive it from the calling context) so the condition can be `fixingArtistId === artist.account_id || removingArtistId === artist.account_id`.</comment>
<file context>
@@ -33,8 +35,12 @@ const VerifySocialsStep = ({ onConfirmed }: { onConfirmed: () => void }) => {
key={artist.account_id}
artist={artist}
- isFixing={fixingArtistId === artist.account_id}
+ isFixing={
+ fixingArtistId === artist.account_id || removingSocialId !== null
+ }
</file context>
1 participant
Matrix row 12 in chat#1889. Stacked on #1894 (delete-a-social) — both change
ArtistSocialsCard/VerifySocialsStep, so this branches off it rather than conflicting. Review/merge after #1894.Why
VerifySocialsSteprendered every rostered artist's socials expanded simultaneously. For a manager with a real roster that is an unscannable wall, and there is no way to see at a glance which artist still needs attention.What changed
Collapsiblepanel. The trigger shows the artist name plus a profile count — "2 profiles" / "No profiles matched" — so the state is readable while collapsed.defaultOpen={artists.length === 1}), since there is nothing to traverse and an extra click would be pure friction.group-data-[state=open].Uses the existing
@radix-ui/react-collapsibleprimitive (already a dependency, with acomponents/ui/collapsible.tsxwrapper) rather than adding@radix-ui/react-accordion. Same UX, no new dependency.Verification
TDD, red → green:
```
RED — rows rendered regardless of collapse state
Tests 3 failed | 1 passed (4)
GREEN
pnpm exec vitest run components/Onboarding
Test Files 2 passed (2)
Tests 6 passed (6)
```
Tests cover all four behaviours: collapsed by default, the profile-count summary while collapsed, expansion on click revealing the edit affordance, and
defaultOpenfor the single-artist case.pnpm exec tsc --noEmitclean for the touched files. Preview click-through pending (needs an authed multi-artist roster).Tracked in chat#1889 (matrix row 12).
Summary by cubic
Make verify-socials scannable by collapsing socials into per-artist panels with a clear profile count. Also adds the ability to remove a matched profile to undo mistakes.
@radix-ui/react-collapsible; trigger shows artist name and "N profiles"/"No profiles matched", chevron rotates, and a single-artist roster opens by default.SocialRowadds a Remove button next to Edit,useSocialRemovehandles the mutation and refresh, anddeleteArtistSocialcallsDELETE /api/artists/{id}/socials/{socialId}.Written for commit 2856249. Summary will update on new commits.