Yoke date ranges across panels - #744
Conversation
roborev: Combined Review (
|
fc4266c to
e93a7b1
Compare
roborev: Combined Review (
|
roborev: Combined Review (
|
|
do we need a toggle? Seems sensible enough to just DO? |
roborev: Combined Review (
|
roborev: Combined Review (
|
|
I can definitely remove the toggle. |
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Combined Review (
|
399c707 to
3ce1409
Compare
|
rebasing |
roborev: Combined Review (
|
7ed4be0 to
ad26d47
Compare
roborev: Combined Review (
|
ad26d47 to
d2b09fe
Compare
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Combined Review (
|
e9b6348 to
7ed6385
Compare
roborev: Combined Review (
|
7ed6385 to
e6b79f9
Compare
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Review Unavailable (
|
Synchronize date range selection across date-aware panels while preserving each panel's URL and API semantics. The branch keeps sessions, analytics, usage, activity, trends, and insights aligned through a shared yoke state without letting unsupported or stale query params silently change visible data. This replaces a long review-fix stack with one coherent frontend change so the final branch is reviewable as the feature it implements rather than as a sequence of conflict and URL-state repairs. Co-authored-by: Wes McKinney <wesmckinn+git@gmail.com>
Rolling windows keep their window size as durable intent, but several refresh paths reused the previously materialized date range. That let panels claim a relative window while querying stale fixed bounds after the calendar date advanced. Refresh paths now rematerialize rolling ranges before fetching and update URL/yoke state where those materialized bounds are visible. The tests pin the overnight rollover case so the relative label, query params, and shared range state stay aligned.
Session URLs can carry only date_from or only date_to, but the shared yoke adapter treated those as invalid. That left analytics date state on the previous range even though the session list was filtered. Single-bound params now materialize to a concrete analytics range while keeping the session URL fields as the source input. Analytics supplies the earliest known session date for upper-bound-only links when available.
Rolling analytics URLs need both durable rolling intent and materialized session bounds. Without the materialized date filters, session results could drift from the analytics panels even though the URL still advertised a rolling window. Single-bound session dates also need normalized stats bounds in the yoke adapter, and refresh shortcuts should route through the same wrapper paths that update URL and yoke state. This keeps the visible query params, shared date state, and API requests aligned without expanding the date-yoke design.
Rolling analytics URLs now carry both materialized session bounds and window_days. The global sessions URL writeback must keep that rolling intent when the concrete bounds still match, otherwise a rolling link is downgraded to a fixed date link. Manual analytics refreshes now use the same date writeback path as range selection so refreshed rolling bounds update the sidebar/session filters and URL together.
Direct sessions links can start with only window_days before analytics materializes concrete date bounds. The sessions URL writeback must keep that rolling intent during the first materialized update, otherwise the link becomes fixed-date state on the next pass. Centralizing the preserve decision keeps the no-date, first-materialization, and matching-materialization cases in one place instead of spreading date checks through the route sync code.
Rolling session URLs can carry old materialized date_from/date_to values alongside window_days after the calendar advances. Analytics correctly treats window_days as the source of truth, but the sessions URL writeback was comparing against the stale fixed bounds and could downgrade the URL to fixed-date state. Move the session route-param preservation rule into a small testable helper so direct links, first materialization, matching bounds, and refreshed rolling materialization are covered by behavior tests instead of component source assertions.
Clearing materialized session date filters from a rolling URL should remove the rolling window intent too. Otherwise the URL can look cleared while reloads or shared links restore the hidden rolling date filter. Keep preserving window_days for pre-materialized direct links and rolling materializations, but stop carrying it when concrete date filters are intentionally removed. The App source-shape tests now assert their delimiters so future component edits cannot silently widen the checked block.
Clearing session date filters from a rolling sessions URL should leave the main sessions view cleared. The analytics URL hydration effect was treating the missing params as a cue to reapply the current rolling window, which wrote date_from/date_to back into the session filters. When the URL date state disappears and the session date filters are already empty, clear the shared yoke state instead of taking the rolling fallback. This keeps the current view, reload behavior, and shared date seed aligned with the explicit clear action.
Clearing a rolling sessions date filter now leaves the yoke intentionally empty. Refresh still needs to fetch analytics data, but it must not treat the panel's retained internal date range as a new yoke selection and write session date params back into the URL. Track the explicit clear state until another date URL or user date selection reactivates the yoke, so manual and scheduled refreshes preserve the cleared session filter state.
Cleared analytics date state has to survive normal component remounts. A component-local guard is lost when users open a session or navigate away and then return, allowing refresh to write the retained internal analytics range back into session filters. Derive the cleared-yoke guard from shared state instead: no URL date/window params, empty session date filters, and no stored yoke range. That keeps refresh from restoring cleared dates across remounts while explicit date URLs and user date selections still reactivate the yoke.
Date filters can be cleared while AnalyticsPage is unmounted, such as from session detail. In that path the page-level clear effect cannot run, so the stored yoke range can survive and later reseed the cleared dates when the analytics view remounts. Clear the stored yoke from the shared sessions route writeback whenever date/window intent is removed from the URL params. This keeps sidebar clears, detail-route clears, and the analytics remount path aligned.
86e7be3 to
57f0e40
Compare
Clearing session filters from a detail route can remount AnalyticsPage before App's route writeback effects clean up stale date params. Clear the shared date yoke synchronously from the shared filter clear path when date intent is being removed, including routes that only carry rolling window intent. The Insights e2e now expects saved insight links to preserve the active date-yoked query params instead of the pre-yoke bare insight URL.
roborev: Combined Review (
|
The shared window_days query key is used by non-session pages too. Session filter clears should only treat it as session date intent on the sessions route, otherwise clearing unrelated filters on usage can wipe the shared date yoke.
3 participants
This PR adds persisted date yoking across date-aware panels so selecting a date range in sessions analytics, usage, activity, trends, or insights carries across the rest of the viewer. Date yoking is now unconditional: there is no toggle, no opt-out UI, and no persisted enabled flag.
The frontend now has a shared yoke-date store that persists the current range in localStorage, plus URL/yoke precedence rules per panel. Explicit URL date params still win over stored yoke state, bare routes seed from the stored yoke range, and analytics/usage initial fetches wait until URL/yoke date state has been applied.
The UI work removes the old link-button affordance from the top date controls and leaves the existing date pickers/presets as the only visible date controls. Shared local date helpers keep rolling and fixed range materialization consistent across panels, including sessions
window_daysURLs and activity week/month period bounds.Activity adopts only yoked ranges its backend can represent exactly. Longer ranges such as a 1y analytics/usage yoke are left on Activity's current range instead of being silently clipped or causing Activity's one-year custom-range limit to reject the first load.
Reviewers should start with
frontend/src/lib/stores/yokedDates.svelte.ts,frontend/src/App.svelte, and the page integrations underfrontend/src/lib/components/{analytics,usage,activity,trends,insights}/.