Skip to content
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

ilandikov
Copy link
Collaborator

@ilandikov ilandikov commented May 21, 2023

Description

  • 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

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:

  • Bug fix (prefix: fix - non-breaking change which fixes an issue)
  • New feature (prefix: feat - non-breaking change which adds functionality)
  • Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
  • Documentation (prefix: docs - improvements to any documentation content for users)
  • Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)
  • Contributing Guidelines (prefix: contrib - any improvements to documentation content for contributors - see Contributing to Tasks)

Internal changes:

  • Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
  • Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
  • Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Checklist

Terms

@claremacrae
Copy link
Collaborator

How does this relate to PR #1943?
I mean, I think there will be conflicts whichever order this one and that one are merged.

@claremacrae
Copy link
Collaborator

From the PR description it's not obvious if this is talking about renaming the priorities themselves. Something more specific would be really useful.

@claremacrae
Copy link
Collaborator

How does this relate to PR #1943?
I mean, I think there will be conflicts whichever order this one and that one are merged.

If this one is going to go ahead, please do update the user docs, so that a complete PR can be reviewed. Many thanks.

@claremacrae claremacrae added scope: grouping Changes to the grouping capabilities status: user docs need work Needs at least some additions, updates or corrections to user documentation labels May 21, 2023
@ilandikov ilandikov changed the title feat: more readable names in priority feat: remove 'Priority X:' from Priority groups May 22, 2023
@ilandikov
Copy link
Collaborator Author

ilandikov commented May 22, 2023

How does this relate to PR #1943?
I mean, I think there will be conflicts whichever order this one and that one are merged.

On the paper it looks like some adjustment would be needed in PriorityField.ts, but the merge seems to be pretty trivial there. However it is the tests that should have the final word here.

From the PR description it's not obvious if this is talking about renaming the priorities themselves. Something more specific would be really useful.

Indeed! Fixed.

If this one is going to go ahead, please do update the user docs, so that a complete PR can be reviewed. Many thanks.

Yup, after I changed the name of the PR, the update of the docs was self evident, thanks =)

@@ -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());
Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the docs of urgency here and here but didn't find it related to the changes in this PR (Priority group names...).

Do you mean that now sorting of groups from urgency field can use this code? I agree with that, but I guess this should be a different PR.

Copy link
Collaborator

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.

Copy link
Collaborator

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:

  1. change the naming of groups for the Priority field
  2. change the sort of order of grouping for all fields to sort by task sorting order instead of by group name alphabetical order

Copy link
Collaborator Author

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 =)

Copy link
Collaborator Author

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());
Copy link
Collaborator

@claremacrae claremacrae May 22, 2023

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.

Copy link
Collaborator Author

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() if supportsSorting() 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.

Copy link
Collaborator Author

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 ㅠㅠ

@ilandikov ilandikov changed the title feat: remove 'Priority X:' from Priority groups feat: change names of groups from Priority Field and change the sort of order groups same as task sorting order May 22, 2023
@claremacrae
Copy link
Collaborator

Lmk if you wish to have a separate issue for the reversed urgency order =)

I think what this PR has shown is that:

  • When group by was first implemented, all the groups were sorted by name. The test requirements were therefore:
    • A very few tests to confirm that groups were sorted correctly by name - this could be done in (IIRC) Group.test.ts
    • One or two tests of the group names that were generated for each field.
  • Now that per-field sorting of groups is done, there is an obvious gap in the tests:
    • We need a test for each field to show the order in which the group names are sorted...

So I currently see these steps:

PR 1 On the current code, add an expressive test for every field, showing current headings order

It'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 SampleTasks would have static methods that each return an array of Task objects with a representative set of all possible values for a given property.

Examples would be:

  • SampleTasks.withAllPriorities() would be straightforward
  • SampleTasks.withAllDueDateTypes() could return tasks with each of:
    • A valid date - today
    • A valid date - in the past
    • A valid date - in the future
    • An invalid date
    • No date
    • (Maybe SampleTasks.withRepresentativeDueDates() is a better name)

expectGroupHeadingsToBe() could be based on ideas in expectTaskComparesBefore()

The shuffle() call is a nice-to-have, to randomise the order of tasks, so that the tests do not pass by luck

PR 2 Implement the new group sorting mechanism

Do 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 groups

Now the priority group names can be changed easily, and the docs updated, as a small PR.

@ilandikov
Copy link
Collaborator Author

Very clear, thanks a lot! I close this PR since we need to split it.

@ilandikov ilandikov closed this May 24, 2023
@claremacrae
Copy link
Collaborator

In my example test above I called grouper() but it maybe should have been createNormalGrouper() or something…

@claremacrae claremacrae removed the status: user docs need work Needs at least some additions, updates or corrections to user documentation label May 26, 2023
@ilandikov
Copy link
Collaborator Author

ilandikov commented Jun 4, 2023

PR 1 On the current code, add an expressive test for every field, showing current headings order

It's important that we find a more expressive way to test the group headings order than the current very verbose group testing.

test: #1999

PR 2 Implement the new group sorting mechanism

Do not change the names of any groups, but do use the new sorting approach that you are now using in the current PR...

refactor: #2018

PR 3 Rename the priority groups

Now the priority group names can be changed easily, and the docs updated, as a small PR.

@claremacrae
Copy link
Collaborator

PR 1 On the current code, add an expressive test for every field, showing current headings order

It's important that we find a more expressive way to test the group headings order than the current very verbose group testing.

test: #1999

Yeah, sorry I rushed you to create that PR before tests were added for every field.

@claremacrae
Copy link
Collaborator

Yeah, sorry I rushed you to create that PR before tests were added for every field.

Also, the 'expressive' bit is still important 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: grouping Changes to the grouping capabilities
Projects
None yet
Development

Successfully merging this pull request may close these issues.

More readable names in 'group by priority'
2 participants