From a64835fe6dffd73aca319e89d3b7bc74964b826c Mon Sep 17 00:00:00 2001 From: Simon Date: Thu, 16 Jul 2026 09:38:53 +0200 Subject: [PATCH] fix(member-live): re-read view-settings cookie on live navigation --- assets/js/app.js | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/assets/js/app.js b/assets/js/app.js index 90e36102..db1e6322 100644 --- a/assets/js/app.js +++ b/assets/js/app.js @@ -504,21 +504,27 @@ function getCookie(name) { return match ? decodeURIComponent(match[1]) : null } +// `params` is a function so it is re-evaluated on every channel join, not just +// at socket construction. This matters for the member view settings: a live +// navigation back to the overview re-mounts the LiveView on the same socket, so +// the cookie must be re-read at that point — a static params object would echo +// the stale value captured at initial page load (view settings would appear to +// reset until a hard reload). let liveSocket = new LiveSocket("/live", Socket, { longPollFallbackMs: 2500, - params: { + params: () => ({ _csrf_token: csrfToken, timezone: getBrowserTimezone(), view_settings: getCookie("member_view_settings") - }, + }), hooks: Hooks }) // Persist the member-overview view settings per browser/device (§1.5/§1.20). The // LiveView pushes "store-view-settings" (density + compact field toggles) on -// change; we write a long-lived cookie that the LiveView reads back on the next -// full page load (via the request cookie on the dead render and via connect -// params on the connected mount). +// change; we write a long-lived cookie that the LiveView reads back on the dead +// render (via the request cookie) and on every connected mount/join (via the +// connect params, re-evaluated per join — see the LiveSocket params function). // Return the members list to the top after a sort or filter change. The server // resets the keyset stream to page 1 on those changes and pushes this event; a // user scrolled down would otherwise be stranded past the shorter content with