ActiveRecord + Turbo Streams: Persisting Pagination State Across Reflex Calls

Question

Goal
We want to display a large list of records in a Rails view using Reflex to update the list via Turbo Streams, while limiting the number of records per page and preserving the current page across multiple Reflex invocations.
Constraints
Reflex actions are stateless between requests; ActiveRecord scopes can bound a query with limit and offset, but the client does not automatically remember the page number when a Turbo Stream replaces the list. Without explicit state handling, the next “next page” click may reset to page 0 or produce inconsistent results.
Unresolved Decision
The community has not agreed on a standard pattern for persisting pagination parameters across Reflex calls. Options include storing the page number in the session, embedding it in a hidden field, or passing it as a parameter on every Reflex event. Each approach has trade‑offs in security, UX, and complexity.
Questions
1. What is the most secure way to transmit the current page number in a Reflex request without exposing it to tampering?2. Should the page state be stored server‑side (e.g., session) or client‑side (e.g., hidden field) to maintain consistency?3. How can we validate and sanitize pagination parameters to prevent injection or out‑of‑range errors?

Tasadduq Burney · Answer

Answer to the Core Questions

Secure transmission: Store the current page in a signed cookie (`cookies.signed[:page]`). The cookie is encrypted and tamper‑evident; any client‑side modification triggers a verification error, preventing silent tampering.
Server‑side storage: Keep the page number on the server (session or signed cookie). Client‑side hidden fields or data attributes expose the value to manipulation; server‑side storage guarantees consistency even across multiple tabs, as long as you avoid session overwrite conflicts.
Validation & sanitization: On every Reflex call, cast the page to an integer, default to 1 if the cast fails, and clamp it to the valid range `1..max_pages`. If the stored value exceeds the new maximum (e.g., after records are added), reset it to 1.

Practical Steps for Your Reflex‑Powered List

Define a helper to fetch the page:
def current_page
  page = cookies.signed[:page]
  page = page.to_i > 0 ? page.to_i : 1
  page = 1 if page > max_pages
  page
end

Use the page in the query (e.g., with kaminari or will_paginate):
@records = Record.page(current_page).per(20)

Update the cookie after each Reflex action:
def next_page
  cookies.signed[:page] = current_page + 1
  @records = Record.page(cookies.signed[:page]).per(20)
  # Turbo Stream rendering happens automatically
end

Render the list via Turbo Stream (no hidden fields needed):
turbo_stream.replace "records_list", partial: "records/list", locals: { records: @records }

Handle out‑of‑range or tampered values: If `cookies.signed[:page]` raises `ActiveSupport::MessageVerifier::InvalidSignature`, rescue and reset to page 1.
rescue ActiveSupport::MessageVerifier::InvalidSignature
  cookies.signed[:page] = 1
  @records = Record.page(1).per(20)
end

Verification Checklist

Inspect the HTML after a Reflex call: the list should update without any hidden input containing the page number.
Use `rails console`: `cookies.signed[:page]` should persist across requests and reject manual tampering.
Check server logs for `InvalidSignature` errors when you intentionally corrupt the signed cookie in the browser.

Missing Diagnostic Detail
Do you currently use a signed cookie or a session to store user data? Knowing this will help tailor the exact code snippets for your setup.

ActiveRecord + Turbo Streams: Persisting Pagination State Across Reflex Calls

Goal

Constraints

Unresolved Decision

Questions

1 answer

Answer to the Core Questions

Practical Steps for Your Reflex‑Powered List

Verification Checklist

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments