Unify date controls behind a single range picker - #749
Merged
Conversation
Replace the four divergent date controls (DateRangeSelector, Activity's RangeControl + RangeNavigator, and the inline Trends/Insights date inputs) with one shared RangePicker: a popover trigger plus a tabbed panel offering Relative windows, steppable Calendar periods, and a Custom range. Every view now renders the same control. A small selection model (rangeSelection.ts) resolves any selection to the from/to or preset/anchor each store already consumes, so existing behavior is preserved: - Analytics and Usage keep rolling-vs-pinned windows and "All" semantics. - Activity keeps day/week/month period stepping, now inside the panel. - Trends keeps its granularity and normalize controls beside the picker. - Insights keeps single-day selection (Calendar - Day) and its insight-type select, dropping the bespoke mode-coupled inputs. The day/week/month resolution toggles (Analytics chart granularity, Trends grouping, Activity bucket) are intentionally left as their own controls.
…th jitter Address review findings on the unified range picker: - Picking a Relative or Calendar preset while the popover is open now syncs the Custom tab's inputs and the calendar anchor, so switching to Custom edits the range just chosen instead of a stale seed from when it opened. - commitCustom normalizes a reversed range (from > to) before emitting, so consumers and backend validation never receive to < from. Also stabilize the trigger with a min-width and a flex label so the button no longer resizes as the date label changes and shifts neighboring controls.
roborev: Combined Review (
|
…ates The Trends toolbar carried a day/week/month granularity bar right next to the new date picker, whose Calendar tab also offers day/week/month -- two controls with identical labels meaning different things (chart bucketing vs date span). Move the granularity and the normalize toggle out of the date toolbar and into the chart panel's header: a minimal "Group by" dropdown (bar-chart icon, opens Day/Week/Month) plus the normalize checkbox. The top row is now only the date scope, and how the chart is drawn lives where it acts -- matching how Analytics places its own timeline granularity on the chart.
roborev: Combined Review (
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The date controls had drifted into four different shapes across views — Analytics/Usage's preset + input selector, Activity's segmented control plus a separate prev/next navigator, Trends' inline labelled from/to plus a granularity group, and Insights' mode-coupled inputs. Same job, four costumes: three input heights, three preset vocabularies, two active-state styles.
This replaces all of them with one shared
RangePicker: a popover trigger plus a segmented panel (Relative / Calendar / Custom). Every view renders the identical control. Behavior that isn't date selection (Activity's period stepping) lives inside the panel, so the toolbars look the same everywhere.A small selection model (
rangeSelection.ts) resolves any selection to thefrom/toorpreset/anchoreach store already consumes, so existing behavior is preserved rather than reimplemented:Out of scope by design: Analytics' chart granularity and Activity's bucket stay as their own controls. Folding every resolution toggle into one shared control is a possible follow-up.
Where to look:
frontend/src/lib/components/shared/RangePicker.svelte(the control) andrangeSelection.ts(the selection model + date math). Each page's adapter is the smallrangeSelection/applyRangeblock added to its*Page.svelte.DateRangeSelector,RangeControl, andRangeNavigatorare deleted.