feat: add date math for filters #1342
|
@ -174,19 +174,19 @@ const buttonText = computed<string>(() => {
|
|||
<style lang="scss" scoped>
|
||||
.datepicker-with-range-container {
|
||||
position: relative;
|
||||
konrad marked this conversation as resolved
Outdated
|
||||
}
|
||||
|
||||
:deep(.popup) {
|
||||
z-index: 10;
|
||||
margin-top: 1rem;
|
||||
border-radius: $radius;
|
||||
border: 1px solid var(--grey-200);
|
||||
background-color: var(--white);
|
||||
box-shadow: $shadow;
|
||||
:deep(.popup) {
|
||||
z-index: 10;
|
||||
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.
|
||||
margin-top: 1rem;
|
||||
border-radius: $radius;
|
||||
border: 1px solid var(--grey-200);
|
||||
background-color: var(--white);
|
||||
box-shadow: $shadow;
|
||||
|
||||
&.is-open {
|
||||
width: 500px;
|
||||
height: 320px;
|
||||
}
|
||||
&.is-open {
|
||||
width: 500px;
|
||||
height: 320px;
|
||||
}
|
||||
}
|
||||
konrad marked this conversation as resolved
Outdated
dpschen
commented
We could remove this prop if we would only expose the slot for the trigger. We could remove this prop if we would only expose the slot for the trigger.
konrad
commented
Done. Done.
|
||||
|
||||
|
|
|
@ -588,7 +588,7 @@ export default {
|
|||
}
|
||||
</script>
|
||||
|
||||
<style lang="scss">
|
||||
<style lang="scss" scoped>
|
||||
.single-value-control {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
|
@ -598,7 +598,7 @@ export default {
|
|||
}
|
||||
}
|
||||
|
||||
.datepicker-with-range-container .popup {
|
||||
:deep(.datepicker-with-range-container .popup) {
|
||||
right: 0;
|
||||
}
|
||||
</style>
|
||||
|
|
Reference in New Issue
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
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?
I think I encountered at least something like external stuff first in a linter already.