-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/2824 date input #2864
base: next
Are you sure you want to change the base?
Feature/2824 date input #2864
Conversation
fixes #2824 |
data={orders_by_day} | ||
dates=day | ||
title="Select a Date Input" | ||
range |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this example uses a range, but is in the wrong section? remove?
range |
select | ||
* | ||
from ${orders_by_day} | ||
where day = '${inputs.range_filtering_a_query.value}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This example chart looks odd, A barchart with a single day is rarely used.
I think you'd be using this as a one sided filter.
where day = '${inputs.range_filtering_a_query.value}' | |
where day > '${inputs.range_filtering_a_query.value}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh nice yeah, i like this better
/> | ||
<PropListing | ||
name="title" | ||
options="string" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it looks odd to just have a floating number in a button. not obvious what to do without a title?
Maybe we can make this title a default?
I know @mcrascal has an different view so happy to discuss
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah it's definitely missing something, and easily overlooked on its own
@@ -0,0 +1,302 @@ | |||
--- | |||
title: Date Input | |||
sidebar_position: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor point, we should have a description:
- we should be doing this for all components going forward
- orders_by_day.sql | ||
--- | ||
|
||
Creates a date picker that can be used to filter a query. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creates a date picker that can be used to filter a query. | |
A date input component allows the user to select a date or a range of dates. The selected dates can be used as inputs to queries or components. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be the description also
Date Input w/ calendar (@steeze-ui/svelte-icon) Date Input w/ inline title Date Input w/ range + title (no calendar icon) |
calendar icon is improved The separating bar between the Date Input and Jan 1, 1970 looks different to that used in the Dropdown to me (too heavy, does not extend high or low enough) Can we match the styling |
Here are some options we can fix with custom stroke width, and perhaps exploring other icons. I think I'm noticing we can fix some pixelation with a lower stroke width when the text is black. Calendar stroke-[1.8px] text-black stroke-[2px] stroke-[2.1px] stroke-[2.2px] Calendar Down stroke-[2px] Calendar Event stroke-[2px] |
I think maybe |
although I actually like what is currently in the deploy preview |
@archiewood |
Calendar event looks great! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also needs engineering code review from as the changes are quite surgical.
packages/ui/core-components/src/lib/atoms/inputs/date-range/DateRange.svelte
Show resolved
Hide resolved
Moved some functions used both in DateRange and DateInput, into a helper.js I tried moving some of the query-building logic/ input store, but it felt like my changes were making the code more complicated, so I left them in the respective components. |
export let data; | ||
/** @type {string | undefined} */ | ||
export let dates; | ||
/** @type {[]string | undefined} */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** @type {[]string | undefined} */ | |
/** @type {string[] | undefined} */ |
/** @type {string} */ | ||
export let name; | ||
/** @type {string | undefined} */ | ||
export let title; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
optional props like these should have a default value of undefined
, otherwise a bunch of warnings pop up in dev
if (range) { | ||
$inputs[name] = { value: undefined, start: startString, end: endString }; | ||
} else { | ||
$inputs[name] = { value: startString, start: startString, end: undefined }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we set start
here? Seems more like it should just be start/end
for range vs. value
for non-range
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I'd prefer to omit the undefined props rather than giving them the value of undefined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was my suggestion
My initial thought was start is probably worth keeping start
as someone might change from <DateInput range=true
to range=false
, and then it break the rest of their code.
honestly, probably should remove start
from DateInput range=false
now I think about it you are likely going to have to change the SQL anyway from between
to =
selectedPreset = targetPreset; | ||
if (range) { | ||
selectedDateInput = targetPreset.range ?? targetPreset.value; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could be wrong, but the targetPreset.value
seems like dead code - doesn't seem like we allow .value
in elements of presets
{:else if selectedDateInput && !range} | ||
{#if title} | ||
{title} | ||
<Separator oritentation="vertical" class="mx-2 h-4 w-[1px]" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<Separator oritentation="vertical" class="mx-2 h-4 w-[1px]" /> | |
<Separator orientation="vertical" class="mx-2 h-4 w-[1px]" /> |
|
||
$: range = toBoolean(range); | ||
|
||
const exec = getQueryFunction(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ItsMeBrianD is there an alternative we should prefer to direct Query.create
/getQueryFunction
here
|
||
// Mock "today" | ||
import MockDate from 'mockdate'; | ||
MockDate.set('2024-12-30'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this persist after you switch to another story?
Would probably be good to reset it
MockDate.set('2024-12-30'); | |
MockDate.set('2024-12-30'); | |
onMount(() => () => MockDate.reset()); |
} | ||
} | ||
|
||
let currentDate = dateToYYYYMMDD(new Date(Date.now())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let currentDate = dateToYYYYMMDD(new Date(Date.now())); | |
let currentDate = dateToYYYYMMDD(new Date()); |
new Date()
will create a date with the current date/time, no need for Date.now()
@@ -39,6 +36,9 @@ | |||
/** @type {string | undefined} */ | |||
export let defaultValue; | |||
|
|||
/** @type {boolean} */ | |||
let range = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a range
prop on DateRange
? DateRange
should always be a range in my opinion
/** @type {string | undefined} */ | ||
export let defaultValue; | ||
/** @type {boolean} */ | ||
export let range = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any user facing boolean should accept a string also
<DateInput
range=true
/>
as well as
<DateInput
range={true}
/>
Description
Created DateInput component that builds off the DateRange structure. Redirects /components/date-range/ --> /components/date-input/
Allows users to access a single date or ranged date input calendar
Checklist