Summary
In src/main/resources/static/js/app.js, the loadDashboardTickets() function has two issues that should be addressed:
1. Sequential (wasteful) fetches
Every dashboard load and filter change fires two back-to-back requests:
/tickets?status=&priority=&search=&assignedStaffId= (for computing stat counts)/tickets?{actual filters} (for the visible ticket list)
These are fired sequentially, doubling backend load and wall-clock time. The fix is to parallelise them with Promise.all, or — ideally — introduce a lightweight GET /api/tickets/stats endpoint that returns just {total, open, inProgress, closed} counts to avoid transferring the full ticket payload for counting purposes.
2. Empty enum strings sent as query params
The stats fetch always appends empty strings for status, priority, search, and assignedStaffId. Passing "" for enum-typed params (Status, Priority) is fragile — Spring's binding behavior for empty strings depends on the ConversionService configuration and Spring version. The fix is to build query strings with URLSearchParams and only append a key when its value is non-empty.
Suggested approach
const filteredParams = new URLSearchParams();
if (s) filteredParams.append("status", s);
if (p) filteredParams.append("priority", p);
if (q) filteredParams.append("search", q);
if (staffId) filteredParams.append("assignedStaffId", staffId);
const filteredQuery = filteredParams.toString() ? `?${filteredParams.toString()}` : "";
const [statsRes, ticketsRes] = await Promise.all([
apiFetch("/tickets"),
apiFetch(`/tickets${filteredQuery}`)
]);References
Summary
In
src/main/resources/static/js/app.js, theloadDashboardTickets()function has two issues that should be addressed:1. Sequential (wasteful) fetches
Every dashboard load and filter change fires two back-to-back requests:
/tickets?status=&priority=&search=&assignedStaffId=(for computing stat counts)/tickets?{actual filters}(for the visible ticket list)These are fired sequentially, doubling backend load and wall-clock time. The fix is to parallelise them with
Promise.all, or — ideally — introduce a lightweightGET /api/tickets/statsendpoint that returns just{total, open, inProgress, closed}counts to avoid transferring the full ticket payload for counting purposes.2. Empty enum strings sent as query params
The stats fetch always appends empty strings for
status,priority,search, andassignedStaffId. Passing""for enum-typed params (Status,Priority) is fragile — Spring's binding behavior for empty strings depends on the ConversionService configuration and Spring version. The fix is to build query strings withURLSearchParamsand only append a key when its value is non-empty.Suggested approach
References