-
-
Notifications
You must be signed in to change notification settings - Fork 223
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
feat: change names of groups from Priority Field and change the sort of order groups same as task sorting order #1966
Conversation
How does this relate to PR #1943? |
From the PR description it's not obvious if this is talking about renaming the priorities themselves. Something more specific would be really useful. |
If this one is going to go ahead, please do update the user docs, so that a complete PR can be reviewed. Many thanks. |
On the paper it looks like some adjustment would be needed in
Indeed! Fixed.
Yup, after I changed the name of the PR, the update of the docs was self evident, thanks =) |
src/Query/Filter/Field.ts
Outdated
@@ -360,7 +360,7 @@ export abstract class Field { | |||
* @param reverse - false for normal group order, true for reverse group order. | |||
*/ | |||
public createGrouper(reverse: boolean): Grouper { | |||
return new Grouper(this.fieldNameSingular(), this.grouper(), reverse); | |||
return new Grouper(this.fieldNameSingular(), this.grouper(), reverse, this.comparator()); |
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 thing this will change (improve) the sort order for urgency grouping.
Which will just require confirmation and then a change the docs of group by urgency please.
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.
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.
It’s this text:
- Currently, the groups run from the lowest urgency to highest.
- You can reverse this with group by urgency reverse.
- In a future release, the default group order will become from the highest urgency to lowest.
I am reasonably confident that this PR has done point 3 and the above text should be updated.
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.
didn't find it related to the changes in this PR (Priority group names...).
To be more specific, this PR does several things:
- change the naming of groups for the Priority field
- change the sort of order of grouping for all fields to sort by task sorting order instead of by group name alphabetical order
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.
You are right! I wrote a test and tried it before and after all the changes and it does change the behaviour indeed. Test and docs.
Now I'm thinking that I should've probably split the PR in 2 - one for refactoring with addition of the comparator to the grouper and the other one to fix the Priority group names. May be a third for the Urgency =)
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.
Lmk if you wish to have a separate issue for the reversed urgency order =)
@@ -64,7 +64,7 @@ export abstract class MultiTextField extends TextField { | |||
* This overloads {@link Field.createGrouper} to put a plural field name in the {@link Grouper.property}. | |||
*/ | |||
public createGrouper(reverse: boolean): Grouper { | |||
return new Grouper(this.fieldNamePlural(), this.grouper(), reverse); | |||
return new Grouper(this.fieldNamePlural(), this.grouper(), reverse, this.comparator()); |
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.
What happens with this code if the field does not implement sorting?
I expect that calling this.comparator()
will then throw some kind of exception.
If you look at the Quick Reference table you will find a few such cases - such as recurrence or recurring (I forget which).
And certainly the new group by function
will create a grouper that does not sort.
So... you could write a failing test using recurrence, but if it is taught to sort in future, that test will become useless.
So the testing trick here is to write a new test and have it use a simple implementation for Field that does grouping but not sorting. Perhaps DescriptionLengthGroupingfield
. A field that is written purely to make testing easy and self-explanatory.
Then line 67 can be changed to only use this.comparator()
if supportsSorting()
is true, and if not, fall back on the old behaviour of sorting by group name.
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.
What happens with this code if the field does not implement sorting?
I expect that calling
this.comparator()
will then throw some kind of exception.
Very good point, thanks.
So the testing trick here is to write a new test and have it use a simple implementation for Field that does grouping but not sorting. Perhaps
DescriptionLengthGroupingfield
. A field that is written purely to make testing easy and self-explanatory.
Yup, I did that now, this seems to be a good trade-off.
Then line 67 can be changed to only use
this.comparator()
ifsupportsSorting()
is true, and if not, fall back on the old behaviour of sorting by group name.
On Field
level I don't have access to the group names so I can't compare them in the fall back case. I'm not really sure how to solve this.
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.
Ok, I think I got this, but not sure whether it is a good solution. Something smells here, can't tell what exactly. Probably the whole direction of the development ㅠㅠ
I think what this PR has shown is that:
So I currently see these steps: PR 1 On the current code, add an expressive test for every field, showing current headings orderIt's important that we find a more expressive way to test the group headings order than the current very verbose group testing. For this PR, this is the sort of thing I mean by expressive (typed from memory without an IDE) expectGroupHeadingsToBe(
new PriorityField().grouper(),
shuffle(SampleTasks.withAllPriorities()),
[
'Priority 1: High',
'Priority 2: Medium',
'Priority 3: None',
'Priority 4: Low',
]
); I am thinking that Examples would be:
The PR 2 Implement the new group sorting mechanismDo not change the names of any groups, but do use the new sorting approach that you are now using in the current PR... The new tests will confirm whether I am correct - but I think you will find that only the urgency order will be changed - and it is an improvement. If I am correct that only urgency changes, then this can actually be labeled as bug-fix, to group most urgent tasks first... and just update the urgency grouping docs. PR 3 Rename the priority groupsNow the priority group names can be changed easily, and the docs updated, as a small PR. |
Very clear, thanks a lot! I close this PR since we need to split it. |
In my example test above I called grouper() but it maybe should have been createNormalGrouper() or something… |
test: #1999
refactor: #2018
|
Yeah, sorry I rushed you to create that PR before tests were added for every field. |
Also, the 'expressive' bit is still important 😄 |
Description
Motivation and Context
Fixes #1628 . Priority groups are now displayed without numbers:
High
,Medium
,None
,Low
, but are sorted in the same order and not in alphabetical order (High
,Low
,Medium
,None
).How has this been tested?
Screenshots (if appropriate)
Types of changes
Changes visible to users:
fix
- non-breaking change which fixes an issue)feat
- non-breaking change which adds functionality)feat!!
orfix!!
- fix or feature that would cause existing functionality to not work as expected)docs
- improvements to any documentation content for users)vault
- improvements to the Tasks-Demo sample vault)contrib
- any improvements to documentation content for contributors - see Contributing to Tasks)Internal changes:
refactor
- non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)test
- additions and improvements to unit tests and the smoke tests)chore
- examples include GitHub Actions, issue templates)Checklist
yarn run lint
.Terms