feat: add date math for filters #1342

Merged
konrad merged 88 commits from feature/date-math into main 2022-03-28 17:30:43 +00:00
1 changed files with 17 additions and 13 deletions
Showing only changes of commit dabe87af4b - Show all commits

View File

@ -47,6 +47,18 @@ import {LOADING, LOADING_MODULE} from '@/store/mutation-types'
import LlamaCool from '@/assets/llama-cool.svg?component'
import DatepickerWithRange from '@/components/date/datepickerWithRange'
function parseDate(query, fallback) {
if (typeof query === 'undefined') {
return fallback
}
const d = new Date(query)
return !isNaN(d)
? d
: query
}
function getNextWeekDate() {
return new Date((new Date()).getTime() + 7 * 24 * 60 * 60 * 1000)
}
@ -82,18 +94,10 @@ export default {
},
computed: {
dateFrom() {
const d = new Date(Number(this.$route.query.from))
return !isNaN(d)
? d
: new Date()
return parseDate(this.$route.query.from, new Date())
konrad marked this conversation as resolved Outdated

Unsure: I think eslint doesn't complain here if you use underscore (_) to spread the unused variable.

Unsure: I think eslint doesn't complain here if you use underscore (`_`) to spread the unused variable.

Add ?.[0] so we return the key, which is what we actually want to use and adjust variable name.

Add `?.[0]` so we return the key, which is what we actually want to use and adjust variable name.

Unsure: I think eslint doesn't complain here if you use underscore (_) to spread the unused variable.

Nope, does not seem to have an effect.

> Unsure: I think eslint doesn't complain here if you use underscore (_) to spread the unused variable. Nope, does not seem to have an effect.

Add ?.[0] so we return the key, which is what we actually want to use and adjust variable name.

Done.

> Add ?.[0] so we return the key, which is what we actually want to use and adjust variable name. Done.

Nope, does not seem to have an effect.

Interesting!

> Nope, does not seem to have an effect. Interesting!
},
konrad marked this conversation as resolved Outdated

Readd route props

Readd route props

Changed it to route props.

However, we still have a dependency on the router: every time when seleting a date in ShowTasks it will push the change to the route. I don't know how to change that without massively overengeneering everything so I'd say we leave it at that.

Changed it to route props. However, we still have a dependency on the router: every time when seleting a date in ShowTasks it will push the change to the route. I don't know how to change that without massively overengeneering everything so I'd say we leave it at that.

I think it's fine for now. I thought a while about this but also don't have a better soltion for this at the moment (except the v-model version)

I think it's fine for now. I thought a while about this but also don't have a better soltion for this at the moment (except the v-model version)

Remove title var and return directly:

if (typeof predefinedRange !== 'undefined') {
    return t(`input.datepickerRange.ranges.${predefinedRangeKey}`)
} else {
    return showAll
			? t('task.show.titleCurrent')
			: t('task.show.fromuntil', {
				from: formatDate(dateFrom, 'PPP'),
				until: formatDate(dateTo, 'PPP'),
			})
}
Remove title var and return directly: ```js if (typeof predefinedRange !== 'undefined') { return t(`input.datepickerRange.ranges.${predefinedRangeKey}`) } else { return showAll ? t('task.show.titleCurrent') : t('task.show.fromuntil', { from: formatDate(dateFrom, 'PPP'), until: formatDate(dateTo, 'PPP'), }) }

Done.

Done.
dateTo() {
const d = new Date(Number(this.$route.query.to))
return !isNaN(d)
? d
: getNextWeekDate()
return parseDate(this.$route.query.to, getNextWeekDate())
},
showNulls() {
return this.$route.query.showNulls === 'true'
@ -138,8 +142,8 @@ export default {
this.$router.push({
name: this.$route.name,
query: {
from: +new Date(dateFrom ?? this.dateFrom),
to: +new Date(dateTo ?? this.dateTo),
from: dateFrom ?? this.dateFrom,
to: dateTo ?? this.dateTo,
showOverdue: this.showOverdue,
showNulls: this.showNulls,
dpschen marked this conversation as resolved Outdated

Mhh that is a bit annoying that we have to convert to strings here :/
But I also don't have a better idea for now.
Right now this might be still fine, but I remember similar usecases where the conversion from state object to the url representation was quite complex.

We might need to abstract this in the future, so let's keep that in the back of our head =)

Mhh that is a bit annoying that we have to convert to strings here :/ But I also don't have a better idea for now. Right now this might be still fine, but I remember similar usecases where the conversion from state object to the url representation was quite complex. We might need to abstract this in the future, so let's keep that in the back of our head =)
},
@ -185,7 +189,7 @@ export default {
params.filter_by.push('due_date')
params.filter_value.push(this.dateTo)
params.filter_comparator.push('less')
// NOTE: Ideally we could also show tasks with a start or end date in the specified range, but the api
// is not capable (yet) of combining multiple filters with 'and' and 'or'.