Skip to content

fixed-issue-#51-imroved-pipline#54

Merged
JoachimLK merged 1 commit into
mainfrom
ux/improve-filters-sync-&-pipeline
Feb 27, 2026
Merged

fixed-issue-#51-imroved-pipline#54
JoachimLK merged 1 commit into
mainfrom
ux/improve-filters-sync-&-pipeline

Conversation

@JoachimLK
Copy link
Copy Markdown
Contributor

@JoachimLK JoachimLK commented Feb 27, 2026

Summary

  • What does this PR change?
  • Why is this needed?

Type of change

  • [x ] Bug fix
  • [x ] Feature
  • Refactor
  • Docs
  • Chore

Validation

  • [ x] I tested locally
  • I added/updated relevant documentation
  • I verified multi-tenant scoping and auth behavior for affected API paths

DCO

  • All commits in this PR are signed off (Signed-off-by) via git commit -s

Summary by CodeRabbit

Release Notes

  • New Features

    • Dashboard filters (status and view mode) now persist in the URL, allowing shareable and bookmarkable filter states across applications and jobs pages.
    • Pipeline overview redesigned with a segmented progress bar showing individual pipeline statuses as clickable segments.
    • Added status cards grid displaying pipeline stage counts with percentages alongside the visualization.
    • Pipeline header now includes a total count badge.
  • UI/UX Improvements

    • Enhanced empty pipeline state messaging and visual presentation.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Feb 27, 2026

📝 Walkthrough

Walkthrough

The changes introduce route query synchronization across three dashboard pages, enabling filter states to persist in the URL and be restored on navigation. Additionally, the main dashboard redesigns the pipeline visualization with a segmented progress bar and cards-based stage display.

Changes

Cohort / File(s) Summary
Route Query Synchronization
app/pages/dashboard/applications/index.vue, app/pages/dashboard/jobs/index.vue
Adds route-based initialization and two-way synchronization for filters: reads initial status/view modes from route.query, watches for state changes, and updates URL via router.replace to persist filters across navigation.
Pipeline Visualization Redesign
app/pages/dashboard/index.vue
Overhauls pipeline section with segmented progress bar (replacing simple bar), responsive Stage cards grid (replacing legend), total-count badge in header, and refreshed empty state visuals (Inbox icon and updated messaging).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

  • reqcore-inc/reqcore#46: Modifies the same applications filter file with route query handling and parameter passing logic.
  • reqcore-inc/reqcore#47: Updates the same applications page status filtering with client-side state management and related filter restructuring.

Poem

🐰 Routes synchronized, filters persist,
Where queries and states gently exist,
Pipelines now segment, cards brightly display,
Dashboard hops forward in a sophisticated way! 🌿

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name Status Explanation Resolution
Description check ⚠️ Warning The description template is not filled out; it contains placeholder text and lacks specific details about what changed, why it was needed, or implementation details. Complete the summary section with concrete details about the changes (filter synchronization, pipeline UI improvements) and the reasons for these changes. Also sign off commits per DCO requirements.
Title check ❓ Inconclusive The title is vague and contains a typo ('imroved' instead of 'improved'); it references issue #51 but doesn't clearly describe what the main change is. Clarify the title to specifically describe the primary change, e.g., 'Add URL-based filter persistence to dashboard and improve pipeline visualization' and fix the typo.
✅ Passed checks (1 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch ux/improve-filters-sync-&-pipeline

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@railway-app
Copy link
Copy Markdown

railway-app Bot commented Feb 27, 2026

🚅 Deployed to the reqcore-pr-54 environment in applirank

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
app/pages/dashboard/applications/index.vue (1)

44-54: Watch triggers router.replace on every client-side navigation.

When activeStatus.value is reassigned at line 41, the watcher fires and calls router.replace even if the URL already matches. This is unnecessary overhead and may cause subtle issues with browser history.

Consider adding a guard to skip the replace if the query already matches:

Proposed optimization
 // Sync the URL when the status filter changes
 watch(activeStatus, (newStatus) => {
+  const currentStatus = route.query.status as string | undefined
+  if (newStatus === currentStatus || (!newStatus && !currentStatus)) return
+
   const query = { ...route.query }
   if (newStatus) {
     query.status = newStatus
   }
   else {
     delete query.status
   }
   router.replace({ query })
 })
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/applications/index.vue` around lines 44 - 54, The watcher
on activeStatus currently calls router.replace on every change even when the URL
already reflects the same status; modify the watch callback (the activeStatus
watcher that receives newStatus) to first compare route.query.status to the
intended value and only call router.replace if they differ (handle the case
where newStatus is falsy by checking absence/undefined of route.query.status),
i.e., compute the desired query.status and skip router.replace when
route.query.status === desiredStatus so you avoid unnecessary replacements.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/pages/dashboard/applications/index.vue`:
- Around line 35-54: The cached activeStatus can remain stale when
route.query.status is absent; update the initialization logic so
activeStatus.value is always set to reflect initialAppStatus (including when
initialAppStatus is undefined) instead of only when !== undefined. In practice,
replace the conditional guard around activeStatus.value assignment for the
useState('app-filter-status') so that activeStatus.value = initialAppStatus runs
unconditionally (or explicitly set activeStatus.value = undefined when
route.query.status is missing), referencing initialAppStatus, activeStatus,
useState, route.query, watch and router.replace to keep the UI state and URL in
sync.

---

Nitpick comments:
In `@app/pages/dashboard/applications/index.vue`:
- Around line 44-54: The watcher on activeStatus currently calls router.replace
on every change even when the URL already reflects the same status; modify the
watch callback (the activeStatus watcher that receives newStatus) to first
compare route.query.status to the intended value and only call router.replace if
they differ (handle the case where newStatus is falsy by checking
absence/undefined of route.query.status), i.e., compute the desired query.status
and skip router.replace when route.query.status === desiredStatus so you avoid
unnecessary replacements.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 01c10b0 and 07cc740.

📒 Files selected for processing (3)
  • app/pages/dashboard/applications/index.vue
  • app/pages/dashboard/index.vue
  • app/pages/dashboard/jobs/index.vue

Comment on lines +35 to +54
const initialAppStatus = STATUS_OPTIONS.includes(route.query.status as any)
? (route.query.status as Status)
: undefined
const activeStatus = useState<Status | undefined>('app-filter-status', () => initialAppStatus)
// Ensure the state matches the URL on navigation (useState caches across client-side navigations)
if (initialAppStatus !== undefined) {
activeStatus.value = initialAppStatus
}

// Sync the URL when the status filter changes
watch(activeStatus, (newStatus) => {
const query = { ...route.query }
if (newStatus) {
query.status = newStatus
}
else {
delete query.status
}
router.replace({ query })
})
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Potential stale state issue when navigating without query params.

The guard at lines 40-42 only updates activeStatus when initialAppStatus !== undefined. If a user navigates to /dashboard/applications (no ?status= param) after previously visiting /dashboard/applications?status=new, the useState cache retains the old value ('new'), but the URL shows no filter.

This creates a mismatch: the UI filters by 'new' while the URL suggests no filter is active.

Proposed fix
 const initialAppStatus = STATUS_OPTIONS.includes(route.query.status as any)
   ? (route.query.status as Status)
   : undefined
 const activeStatus = useState<Status | undefined>('app-filter-status', () => initialAppStatus)
 // Ensure the state matches the URL on navigation (useState caches across client-side navigations)
-if (initialAppStatus !== undefined) {
-  activeStatus.value = initialAppStatus
-}
+activeStatus.value = initialAppStatus
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/applications/index.vue` around lines 35 - 54, The cached
activeStatus can remain stale when route.query.status is absent; update the
initialization logic so activeStatus.value is always set to reflect
initialAppStatus (including when initialAppStatus is undefined) instead of only
when !== undefined. In practice, replace the conditional guard around
activeStatus.value assignment for the useState('app-filter-status') so that
activeStatus.value = initialAppStatus runs unconditionally (or explicitly set
activeStatus.value = undefined when route.query.status is missing), referencing
initialAppStatus, activeStatus, useState, route.query, watch and router.replace
to keep the UI state and URL in sync.

@JoachimLK JoachimLK merged commit e136ffc into main Feb 27, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant