Add project dashboard with entry progress tracking#2397
Conversation
Wire the dev-only dashboard route and show dictionary progress toward 10k entries, including per-writing-system field completion with compact circular progress indicators. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR adds a new Project Dashboard feature: a ChangesDashboard feature
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
github-actions
Bot
added
the
💻 FW Lite
Co-authored-by: Cursor <cursoragent@cursor.com>
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
|
I also wanted to have some fun 😉 So, I made a few adjustments and an addition at the end. I tried to change the first card, so it doesn't have a generic, overwhelming 10,000 goal. AI whipped up some milestones. 
|
|
@myieye you didn't push your changes... |
- Replace fixed 10,000-entry goal with a next-milestone progress hero; drop the redundant Total entries card (the count is now the hero number) - Add a "What would you like to see here?" feedback card that deep-links to a prefilled forum suggestion; share the community URLs via community-links.ts - Encouraging, non-servile, translation-friendly copy; scrollbar padding fix Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
frontend/viewer/src/project/dashboard/DashboardView.svelte (1)
105-134: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicated percent-calculation logic instead of reusing shared
completion()helper.Lines 113-116 and 127-130 reimplement the same
total === 0 ? 0 : Math.round((filled / total) * 100)formula already defined ascompletion()indashboard-stats.ts. Exportingcompletion(or better, havingDashboardStats.entriesWithSenses/entriesWithExamplesbeFieldCompletionobjects computed once infetchDashboardStats) would remove this duplication and prevent the two implementations from silently diverging.♻️ Suggested change
-export type DashboardStats = { - totalEntries: number; - entriesWithSenses: number; - entriesWithExamples: number; +export type DashboardStats = { + totalEntries: number; + entriesWithSenses: FieldCompletion; + entriesWithExamples: FieldCompletion; milestone: MilestoneProgress | undefined; vernacular: VernacularWritingSystemStats[]; analysis: AnalysisWritingSystemStats[]; };Then in
DashboardView.svelte, usedashboard.entriesWithSenses.filled/.percentdirectly viaformatCompletion(dashboard.entriesWithSenses, dashboard.totalEntries).🤖 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 `@frontend/viewer/src/project/dashboard/DashboardView.svelte` around lines 105 - 134, The percent calculation is duplicated in DashboardView instead of reusing the shared completion helper from dashboard-stats. Update DashboardStats or fetchDashboardStats so entriesWithSenses and entriesWithExamples are computed once as FieldCompletion values via completion(), then have DashboardView.svelte pass those objects directly to formatCompletion rather than recalculating filled/percent inline. Use the completion symbol and the DashboardStats fields to locate the affected logic.frontend/viewer/src/project/dashboard/dashboard-stats.ts (1)
101-120: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low valueLarge fan-out of concurrent
countEntriescalls per writing system.For N vernacular + M analysis writing systems, this issues
1 + 2 + 3N + 2MconcurrentcountEntriescalls. For dev-only usage with few writing systems this is fine, but could add noticeable load/latency as writing systems or corpus size grow.🤖 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 `@frontend/viewer/src/project/dashboard/dashboard-stats.ts` around lines 101 - 120, The fetchDashboardStats routine is creating too many concurrent countEntries requests by expanding per-writing-system checks inside Promise.all, which scales to 1 + 2 + 3N + 2M calls. Refactor fetchDashboardStats and its filledCount usage so the per-writing-system counts are batched or computed in fewer requests, grouping vernacular and analysis lookups instead of firing one request per field per writing system. Keep the same DashboardStats output while reducing the fan-out in this function.
🤖 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 `@frontend/viewer/src/project/dashboard/dashboard-stats.ts`:
- Around line 72-99: The vernacular and analysis stat mappers are relying on
fragile positional ordering from `fetchDashboardStats`, so a change in
`filledCount` call order can silently assign counts to the wrong fields.
Refactor `mapVernacularStats` and `mapAnalysisStats` to consume named values
instead of `index++` over a flat array, and update `fetchDashboardStats` to
return per-field objects (for example, one object per writing system) that the
mappers can destructure by property name.
---
Nitpick comments:
In `@frontend/viewer/src/project/dashboard/dashboard-stats.ts`:
- Around line 101-120: The fetchDashboardStats routine is creating too many
concurrent countEntries requests by expanding per-writing-system checks inside
Promise.all, which scales to 1 + 2 + 3N + 2M calls. Refactor fetchDashboardStats
and its filledCount usage so the per-writing-system counts are batched or
computed in fewer requests, grouping vernacular and analysis lookups instead of
firing one request per field per writing system. Keep the same DashboardStats
output while reducing the fan-out in this function.
In `@frontend/viewer/src/project/dashboard/DashboardView.svelte`:
- Around line 105-134: The percent calculation is duplicated in DashboardView
instead of reusing the shared completion helper from dashboard-stats. Update
DashboardStats or fetchDashboardStats so entriesWithSenses and
entriesWithExamples are computed once as FieldCompletion values via
completion(), then have DashboardView.svelte pass those objects directly to
formatCompletion rather than recalculating filled/percent inline. Use the
completion symbol and the DashboardStats fields to locate the affected logic.
🪄 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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: aa14056d-125d-419e-9d11-15f9b7c63f20
📒 Files selected for processing (15)
frontend/viewer/src/ShadcnProjectView.sveltefrontend/viewer/src/lib/about/FeedbackDialog.sveltefrontend/viewer/src/lib/about/community-links.tsfrontend/viewer/src/lib/components/ui/circular-progress/circular-progress.sveltefrontend/viewer/src/lib/components/ui/circular-progress/index.tsfrontend/viewer/src/locales/en.pofrontend/viewer/src/locales/es.pofrontend/viewer/src/locales/fr.pofrontend/viewer/src/locales/id.pofrontend/viewer/src/locales/ko.pofrontend/viewer/src/locales/ms.pofrontend/viewer/src/locales/sw.pofrontend/viewer/src/locales/vi.pofrontend/viewer/src/project/dashboard/DashboardView.sveltefrontend/viewer/src/project/dashboard/dashboard-stats.ts
Use named per-field counts instead of positional arrays, and compute senses/examples as FieldCompletion in one place. Co-authored-by: Cursor <cursoragent@cursor.com>
Remove the dev-mode gate so the Dashboard nav item is visible without enabling developer mode. Co-authored-by: Cursor <cursoragent@cursor.com>
2 participants
Summary
/dashboardshowing dictionary progress toward a 10,000 entry goalcountEntriesAPI callsCircularProgresscomponent for inline completion indicators beside count labelsScreenshot
Test plan
/project/{code}/dashboardvia the sidebar Dashboard buttonpnpm run checkinfrontend/viewer