Why does the numbering not work for some uses of v-data-table

Question

The behavior is, I click the next-page chevron and it loads the correct data from the database and goes to the next page, but it does not update the pagination text, which still reads 1-10 of 513. If I use the prev-page and then next-page, so it reads from the cache, this problem does not occur. In a very similar component, the problem never occurs. The code looks like this:

QListComponent.vue

<v-data-table
  :headers="headers"
  :items="items"
  :server-items-length="serverItemsLength"
  :loading="loading"
  @update:options="onOptionsUpdate"
>
...
props: {
   items: Array,
   ...

And it is being used in two components:

BuildingListComponent.vue

<q-list-component :items="buildings">
 ...
props: {
   buildings: Array as PropType<Building[]>,
   ...

and

EmployeeListComponent.vue

<q-list-component :items="employees">
 ...
props: {
   employees: {
      type: Array as PropType<Employee[]>,
      required: true,
   ...

In the BuildingList, the pagination works fine. In the EmployeeList, it only works when reading from the cache. How can this possibly be?

Answer 1

Don’t be too smug if you figured it out. I had to cut off hundreds of lines of irrelevant code to reduce it down the skeleton problem you see.

If you didn’t figure it out, the problem was the employees prop was required, and while the client was loading data from the database, it did not have a value. The invocation of the BuildingList was done like this:

<building-list :buildings="buildingQuery.results" />

But that style with the EmployeeList would have resulted in a compiler error (since results might be Employee[] or it might be undefined), so the line was written like this:

<employee-list :employees="employeeQuery.results || []" />

Removing the empty list (and the required: option that necessitated it) fixed the problem. I guess that this is quirk of Vuetify, to assume that if the list is empty, we must be at the first page.

(Another contributor had a similar seeming problem, with an unrelated cause.)

Or maybe not

In further analysis, I found I was also setting serverItemsLength to undefined while the query was running. Whether this was the true cause of the problem or just another cause of the problem, I now lack the energy to investigate.