feat: add date math for filters #1342
|
@ -22,7 +22,29 @@
|
|||
{{ $t('misc.custom') }}
|
||||
</button>
|
||||
</div>
|
||||
<div class="flatpickr-container">
|
||||
<div class="flatpickr-container input-group">
|
||||
<label class="label">
|
||||
{{ $t('input.datepickerRange.from') }}
|
||||
<div class="field has-addons">
|
||||
<div class="control is-fullwidth">
|
||||
<input class="input" type="text"/>
|
||||
konrad marked this conversation as resolved
Outdated
|
||||
</div>
|
||||
<div class="control">
|
||||
<x-button icon="calendar" variant="secondary" data-toggle/>
|
||||
</div>
|
||||
</div>
|
||||
</label>
|
||||
<label class="label">
|
||||
{{ $t('input.datepickerRange.to') }}
|
||||
<div class="field has-addons">
|
||||
<div class="control is-fullwidth">
|
||||
<input class="input" type="text"/>
|
||||
</div>
|
||||
<div class="control">
|
||||
<x-button icon="calendar" variant="secondary" data-toggle/>
|
||||
</div>
|
||||
</div>
|
||||
</label>
|
||||
<flat-pickr
|
||||
:config="flatPickerConfig"
|
||||
v-model="dateRange"
|
||||
|
@ -54,7 +76,7 @@ const flatPickerConfig = computed(() => ({
|
|||
altInput: true,
|
||||
dpschen marked this conversation as resolved
Outdated
dpschen
commented
I think it's really cool, that we support this, but it would be cool, if we could break this down and explain it in our / simpler terms. I think it's really cool, that we support this, but it would be cool, if we could break this down and explain it in our / simpler terms.
konrad
commented
I think I'm already doing that but wanted to highlight for people who know the syntax from Elasticsearch or Grafana they can use it here as well. Was there anything in the explanation you noticed as not quite understandable? I think I'm already doing that but wanted to highlight for people who know the syntax from Elasticsearch or Grafana they can use it here as well.
Was there anything in the explanation you noticed as not quite understandable?
dpschen
commented
I didn't even check to be honest. I didn't even check to be honest.
Was just something I though of while reading this.
|
||||
dateFormat: 'Y-m-d H:i',
|
||||
enableTime: false,
|
||||
inline: true,
|
||||
wrap: true,
|
||||
mode: 'range',
|
||||
locale: {
|
||||
firstDayOf7Days: weekStart.value,
|
||||
|
@ -137,9 +159,27 @@ const customRangeActive = computed<Boolean>(() => {
|
|||
.flatpickr-container {
|
||||
width: 70%;
|
||||
border-left: 1px solid var(--grey-200);
|
||||
padding: 1rem;
|
||||
font-size: .9rem;
|
||||
|
||||
:deep(input.input) {
|
||||
display: none;
|
||||
// Flatpickr has no option to use it without an input field so we're hiding it instead
|
||||
:deep(input.form-control.input) {
|
||||
height: 0;
|
||||
padding: 0;
|
||||
border: 0;
|
||||
}
|
||||
|
||||
.field .control :deep(.button) {
|
||||
border: 1px solid var(--input-border-color);
|
||||
height: 2.25rem;
|
||||
|
||||
&:hover {
|
||||
konrad marked this conversation as resolved
Outdated
dpschen
commented
Picky: I like to group imports from external packages and from internal stuff.
As you can see this is more or less random, so happy to discuss this. Picky:
I like to group imports from external packages and from internal stuff.
Usally I follow this order (but not strict):
- external packages beginning with vue libs
- external packages other libs and css
- internal instances like store, message, etc
- services and models
- component imports
- helpers
As you can see this is more or less random, so happy to discuss this.
Or we can simple keep it random :D
konrad
commented
Oh I think it absolutely makes sense to have something like that, even if not strictly enforced. Do you think we could put this in a linter? Oh I think it absolutely makes sense to have something like that, even if not strictly enforced. Do you think we could put this in a linter?
dpschen
commented
I think I encountered at least something like external stuff first in a linter already. I think I encountered at least something like external stuff first in a linter already.
|
||||
border: 1px solid var(--input-hover-border-color);
|
||||
}
|
||||
}
|
||||
|
||||
konrad marked this conversation as resolved
Outdated
dpschen
commented
After using it a while I prefer now to use the After using it a while I prefer now to use the `useStore` method to get the current store instance.
The reason is that it makes it easier to refactor in composables later because `useStore` will always give you the store.
konrad
commented
Makes sense! Changed it. Makes sense! Changed it.
|
||||
.label, .input, :deep(.button) {
|
||||
font-size: .9rem;
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -522,6 +522,10 @@
|
|||
"multiselect": {
|
||||
"createPlaceholder": "Create new",
|
||||
"selectPlaceholder": "Click or press enter to select"
|
||||
},
|
||||
"datepickerRange": {
|
||||
"to": "To",
|
||||
"from": "From"
|
||||
}
|
||||
},
|
||||
"task": {
|
||||
|
|
Instead of calling
inputChanged
from here better watch thefrom
and below theto
value.This prevents future mistakes
Changed. I kept
inputChanged
though because I need to watchers.