Implementing Server‑Side Pagination and Sorting in Quasar’s QTable

Desired Outcome

Build a Quasar QTable that retrieves only the rows needed for the current page, supports server‑side sorting, shows a loading spinner while data is fetched, displays errors with a banner, and restores the last pagination state after navigation or refresh.

Prerequisites

• Vue 3 project with Quasar CLI installed (Quasar v2.x).
• Backend API that accepts the query parameters page, per_page, sort_by, and order and returns JSON in the shape:

  {"rows": [...], "totalRows": 12345}

• Optional: Vuex or Pinia store for persisting pagination state.

Step‑by‑Step Setup

1. Create the table component

   /* src/components/ServerTable.vue */
   
     
     
       {{ error }}
     
   
   
   
   

2. Configure the API endpoint
   • Ensure the endpoint accepts page (1‑based index), per_page (number of rows), sort_by (column name), and order ("asc" or "desc").
   • Return a JSON object with rows (array) and totalRows (integer).
3. Persist pagination state
   • The example uses localStorage to remember the last page, rows per page, and sort order. Replace with Vuex/Pinia if preferred.
4. Integrate into a page

   <template>
     <server-table />
   </template>
   
   <script setup>
   import ServerTable from '@/components/ServerTable.vue';
   </script>
   

Validation Checks

• Open the browser dev tools and inspect the network panel. The first request should look like:

  GET /api/items?page=1&per_page=10&sort_by=id&order=asc

• Verify that the table renders exactly rowsPerPage rows. If fewer rows appear, the API might be returning fewer than requested.
• Confirm that the pagination footer shows the correct totalRows value returned by the API.
• While the request is pending, the table should display a QSpinner (enabled by :loading="loading").
• Simulate a 500 response (e.g., by temporarily disabling the API). The QBanner should appear with the error message, and the table should remain empty.

Recovery Options

• API mismatch: If the API returns unexpected query parameters, the table will silently fail. Check the request URL and adjust the fetch call accordingly.
• Inconsistent totalRows: If totalRows changes between requests, the pagination controls may misbehave. Consider refetching the total count on page change or validating against a separate endpoint.
• Large totalRows values: Ensure the client never attempts to render all rows. The example relies on server‑side pagination; if the API mistakenly returns all rows, the table will freeze.
• Missing authentication: If the API requires auth headers, add them to the fetch call and handle token refresh if needed.

Practical Result Check

After implementing the component, reload the page. The first request should fetch page 1. Navigating to page 2 or changing the rows per page should trigger new requests with updated query parameters. The table should update smoothly, and any errors should surface via the banner.