{
  "id": 17173657,
  "title": "After every save, I refetch the page I'm on — not page one",
  "url": "https://urgent.news/2026/10/30/after-every-save-i-refetch-the-page-im-on-not-page-one",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-30T04:17:09.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/kamrankhandev/after-every-save-i-refetch-the-page-im-on-not-page-one-29jo"
  },
  "original_language": "en",
  "account": "A common error occurs when editing a user on an admin table: the page jumps back to the first page, making it unclear whether the edit was successful or not. To fix this issue, my starter kit's Users page simply calls fetchUsers(meta.current_page) after closing the modal, rather than always fetching from page one. This reloads the table with the latest data from the server, ensuring the edited or newly added user appears in the correct position.\n\nThe delete operation follows the same principle: after calling client.delete( /users/ + id), the code still calls fetchUsers(meta.current_page) to keep the page displaying the correct information. An edge case exists when deleting the last row on a page, which would step back a page if the response comes back empty, but the simpler approach of staying on the same page is preferred for the common case.\n\nThe reason for refetching is that the server is the authoritative source for the table's data, and the list endpoint is relatively inexpensive. Instead of attempting to manually update the local row with optimistic updates, one refetch provides the server's ordering, correct page meta, and any concurrent changes made by other admins. Refetching incurs the cost of a single GET request but ensures the admin sees the updated state without guessing.\n\nThe underlying principle here is to trust the server's data and avoid making assumptions about the new state after a mutation. Optimistic updates can improve performance when dealing with slow lists or expensive mutations, but for an admin table over a local API, the refetch approach is fast, simple, and never incorrect. I reserve more advanced techniques for cases where they offer greater value. Keeping the user on the same page might seem trivial, but it significantly enhances trust in the tool and avoids unnecessary navigation to verify changes. The Users page, the paginated API behind it, and the entire admin panel are included in my Laravel + React SaaS Starter Kit, available for $19 as a one-time purchase with Sanctum authentication and role-based access, allowing developers to avoid building these components from scratch.",
  "summary": "Here's a bug I've shipped more than once: you edit a user on page 3 of an admin table, save, and the table jumps back to page 1. The edit worked. The user just isn't visible anymore, and for a second you wonder whether it worked at all. The fix in my starter kit's Users page is one argument: after closing the modal, call fetchUsers(meta.current_page) instead of fetchUsers(1). The modal closes,…",
  "key_points": [
    "Users page refetches data after each edit or delete.",
    "Server data considered authoritative source.",
    "Refetching ensures correct page meta and concurrent changes."
  ],
  "editors_take": "Prioritizing server-side refetching over manual local state updates ensures data integrity and maintains user context, trading a minor network cost for a more reliable and predictable administrative interface.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}