Server‑side processing versus client‑side Ajax loading in DataTables for preserving filter state on reload

Answer

When stateSave is enabled, the configuration that guarantees filter, sort and page state survives a page reload is client‑side Ajax loading (serverSide:false) with the full dataset fetched once.

Confirmed facts

• With serverSide:false DataTables receives the complete data set in the initial Ajax response, stores it in memory, and performs filtering, sorting and pagination locally.
• Because the same data is available after a reload, the built‑in stateSave mechanism (which stores the current draw, search, order and page values in localStorage or cookies) can re‑apply those settings without any additional server logic.
• Research confirms that this behavior works reliably from DataTables 1.10 onward.

Likely explanation

If you choose server‑side processing (serverSide:true), the UI only sends the current draw, start, length, search and order parameters to the server on each request. For the filter to persist after a reload, the server must echo back the exact search[value] (and search[regex]) values it received; otherwise DataTables redraws with an empty search and the saved state is lost. Implementing that echo adds a small but non‑trivial amount of server‑side code (parameter validation and response inclusion).

Steps to achieve guaranteed persistence

1. Set serverSide:false in the DataTables initialization.
2. Provide an Ajax URL that returns the full data set (JSON array or object with a dataSrc property).
3. Enable stateSave:true (default storage is localStorage).
4. Optionally configure stateSaveParams / stateLoadParams if you need to customize what is stored.
5. Test: apply a filter, reload the page, and verify the filter input retains the entered value.

When server‑side may still be viable

If you must keep the initial payload small, you can use serverSide:true provided your backend:

• Accepts the parameters draw, start, length, search[value], search[regex], order.
• Returns a JSON response that includes the same search[value] and search[regex] values under the search object (as required by DataTables).

This adds moderate implementation complexity (parameter handling and echo) but avoids loading the entire data set into the browser.

Memory‑impractical threshold for client‑side Ajax

The client‑side approach becomes impractical when the full data set exceeds the browser’s comfortable memory budget, typically:

• Roughly > 5 – 10 MB of JSON payload.
• Or > ≈ 10 000 rows when each row contains a handful of columns (the exact limit depends on row size and client device).

To give a precise recommendation, we need to know the average size of a single row (or the total number of columns and typical data length). Please provide that detail so we can calculate whether your data set stays within the safe client‑side limit.