feat(settings): add defaultSort user preference for resource table

[7adityaraj]

Add defaultSort user setting for resource table

• Add defaultSort user setting to persist preferred sort column and direction for the resource table. Sort applies on initial load and when switching between resource kinds, instead of resetting to the built-in default.
• Manual column sorts are now automatically persisted — navigating away and back preserves the last sort the user applied
• The default sort is now exposed in the Settings dialog (gear icon → User Preferences section) with a column dropdown and direction toggle, so users don't need to edit files or use the API directly
• The setting is bidirectionally synced: sorting in the table updates the setting, and changing it in Settings applies on next kind switch

Problem

When navigating between resource kinds (Pods → Nodes → Deployments), the table sort resets to the built-in default (name-based) every time. There's no way to persist a preferred sort — users who want resources sorted by age (or any other column) have to manually click the column header after every navigation.

Solution

Added a new defaultSort field to the existing user settings (~/.radar/settings.json). This follows the same pattern as theme and pinnedKinds — persisted to disk, synced via PUT /api/settings, cached in localStorage, and stripped under cloud mode.

When set, the preferred sort applies:

• On initial page load
• When switching between resource kinds

When unset, the existing built-in defaults are preserved (no breaking change).

Example

{
  "defaultSort": {
    "column": "age",
    "direction": "desc"
  }
}

Supported columns: name, namespace, age, status, ready, restarts, cpu, memory, type, version, desired, available, upToDate, lastSeen, count, reason, object. Direction: asc or desc.

---

---

Changes

Backend (Go)

• internal/settings/settings.go — Added DefaultSort struct and field to Settings
• internal/server/server.go — Merge logic in PUT handler, cloud-mode stripping on GET/PUT
• internal/server/server_smoke_test.go — 3 new tests (PUT+persist, preserves existing fields, cloud-mode rejection)

Frontend (TypeScript)

• web/src/hooks/useDefaultSort.ts — New hook (localStorage + server sync, same pattern as theme/pinnedKinds)
• web/src/components/resources/ResourcesView.tsx — Passes defaultSort prop to k8s-ui
• packages/k8s-ui/src/components/resources/ResourcesView.tsx — defaultSort prop on ResourcesViewProps, used for initial state and kind-change reset

Docs

• docs/configuration.md — Added defaultSort to settings reference

Type of change

• New feature (non-breaking change that adds functionality)
• Documentation update

How has this been tested?

• Tested against a remote cluster
• Added/updated unit tests

Ran make test — all 8 settings smoke tests pass (3 new).
Ran make tsc — TypeScript type check clean.
Built with make build, ran ./radar against live EKS cluster, confirmed
age sort applies immediately on load and persists across kind switches.

Checklist

• My code follows the project's coding standards
• I have performed a self-review of my code
• I have added comments where necessary
• My changes generate no new warnings
• Any dependent changes have been merged

Related issues

Fixes #(issue number)

• none

---

Note

Medium Risk
Touches the shared PUT /api/settings merge behavior and cloud-mode stripping/rejection logic, so regressions could affect other user preferences. Frontend changes also alter default sorting behavior across resource kinds and need verification across local vs cloud deployments.

Overview
Adds a new user preference defaultSort (column + direction) that is persisted in ~/.radar/settings.json and exposed via GET/PUT /api/settings, including cloud-mode behavior to strip it from responses and reject writes like other user-scoped fields.

Wires the preference through the UI so resource tables initialize and reset to the configured default when switching kinds, and manual table sorting reports changes via onSortChange so the preference can be updated automatically. Introduces a useDefaultSort hook (localStorage + server sync) and a new User Preferences section in the Settings dialog, plus added smoke/e2e coverage and documentation updates.

^{Reviewed by Cursor Bugbot for commit c70e85a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[nadaverell]

Thanks for the PR!

One thing I'm wondering - this requires manually editing files or API - its not exposed in the settings and not automatically persisted following a user changing sorting.

shuold we at least add this to the settings page?

[7adityaraj]

Thanks for the PR!

One thing I'm wondering - this requires manually editing files or API - its not exposed in the settings and not automatically persisted following a user changing sorting.

shuold we at least add this to the settings page?

hi @nadaverell, thank you for quick reply. Yes, it does not automatically persist following a user changing sorting. Good idea if we can add to setting page as well

[7adityaraj]

hi @nadaverell, the new commit is able to address the persistent of sorting when done manually.

[7adityaraj]

hi @nadaverell please review

[7adityaraj]

Hello @nadaverell , any suggestion for this PR

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1f0acf0. Configure here.}

[cursor]

Settings dropdown missing most supported sort columns

Low Severity

SORT_COLUMNS only lists 4 sortable columns (name, namespace, age, status), but the table supports 17 (including cpu, memory, ready, restarts, type, etc. per the isSortable check in k8s-ui). Since manual column sorts are now auto-persisted via onSortChange, a user who sorts by e.g. "cpu" will see a mismatched <select> state when opening Settings — the controlled value won't match any <option>, causing the dropdown to appear blank or show "None" while the sort is actually active. This misrepresents the current preference and risks accidental data loss if the user interacts with the dropdown.

 

^{Reviewed by Cursor Bugbot for commit 1f0acf0. Configure here.}

[nadaverell]

Hello @nadaverell , any suggestion for this PR

sorry for the delay on this, got lots on my plate. will take a closer look tomorrow, thanks again for contributing!

[7adityaraj]

@nadaverell any thoughts on this PR?