feat: Onboarding Checklist - #2421
Conversation
c455af7 to
fddfd22
Compare
🎩 PreviewA preview build has been created at: |
247aa01 to
a27cdb0
Compare
a27cdb0 to
72eadf3
Compare
65047a8 to
1823626
Compare
ebc0b79 to
3b09b65
Compare
1823626 to
f6fe1e5
Compare
3b09b65 to
30b5b30
Compare
2ac75f1 to
92f5898
Compare
1c9c02e to
dd64845
Compare
92f5898 to
954c86b
Compare
dd64845 to
477bb93
Compare
954c86b to
afe7751
Compare
cd2d469 to
07759d0
Compare
07759d0 to
216959b
Compare
39f9cd8 to
32d29d1
Compare
216959b to
0534c0e
Compare
32d29d1 to
97b3e03
Compare
71d527a to
4384397
Compare
97b3e03 to
9ee3221
Compare
4384397 to
8d51c69
Compare
024a52c to
936b794
Compare
8d51c69 to
0413554
Compare
936b794 to
695a330
Compare
0413554 to
1963c2e
Compare
695a330 to
12a4a92
Compare
|
|
||
| return (next: OnboardingProgress) => { | ||
| if (!hasBackend) return; | ||
| queryClient.setQueryData(queryKey(backendUrl), next); |
There was a problem hiding this comment.
🤖 This is an AI-generated code review comment.
usePersistOnboardingProgress takes a full OnboardingProgress object and writes it directly into the query cache/server. Callers build that object from whatever progress value they currently have, so two onboarding completions close together can race and clobber each other. For example, if markDocsRead and create_pipeline both start from the same cached progress, whichever PATCH/cache write happens last can overwrite the other step back to false.
Suggestion: make the persistence path merge against the latest cached progress before writing, or expose narrower helpers like persistStepCompleted(stepId) / persistDismissed() that read the latest query data and patch only the changed field. That keeps independent onboarding updates from losing each other.
- Render OnboardingHero once, drive placement via CSS order toggle - Document why derived onboarding steps don't emit step.completed - Reconcile onboarding progress cache on PATCH failure via onError Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Description
First PR in a stacked series that builds an onboarding experience for new users (see #622). This one lays the foundation and surfaces the first piece of UI — an onboarding checklist on the Learning Hub.
Foundation (
OnboardingProvider)TourProvidercompletions.userPipelineWriteEvents) emitted from the pipeline-write chokepoints (componentStoreandPipelineFile), so v1 edits, v2 edits, imports, and the new-pipeline button all count./api/users/me/settings), not localStorage. Writes usekeepaliveso a fire-and-forget save survives navigation/reload.UI
OnboardingChecklist— a reusable progress + step-list component (extracted up front so the next PR doesn't have to refactor it).OnboardingHeroon the Learning Hub renders the checklist with progress, per-step CTAs, and a dismiss control.Provider and Onboarding components are enabled in the React Compiler.
Related Issue and Pull requests
Progresses https://github.com/Shopify/oasis-frontend/issues/622
Stacked: #2440 → #2435
Type of Change
Checklist
Screenshots (if applicable)
Test Instructions
Additional Comments
The provider exposes
isReady(queries settled, for routing) vsisResolved(backend resolved + state loaded, for gating visible UI). The downstream pill/welcome PRs rely on this distinction to avoid flicker.