feat: Implementation of Task-Duration (#1649)

[Drezil]

Types of changes

Changes visible to users:

• New feature (prefix: feat - non-breaking change which adds functionality)
  • Issue/discussion: feat: add estimated time (i.e. Duration) to complete in Task #1649
  • WARNING: If the link is absent, the PR may be closed without review, due to the workload that such reviews usually require.
• Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
  • Issue/discussion:
• Bug fix (prefix: fix - non-breaking change which fixes an issue)
  • Issue/discussion:
• Translation (prefix: i18n - additions or improvements to the translations - see Support a new language)
• 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)

Description

Step 1 of #1649 (comment)

Motivation and Context

#1649

How has this been tested?

Currently dogfeeding this PR in my daily obsidian. Will test it extensively - but added it to all tests-suites and i am pretty confident that no issues should arise.

Screenshots (if appropriate)

Checklist

• My code follows the code style of this project and passes yarn run lint.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• My change has adequate Unit Test coverage.

Remaining Issues

• proper documentation
• tooltip to change duration with a predefined set
• Filters/Grouping

this draft-PR gets updated if things tag along. See it as a first preview.

Terms

• My contribution follows this project's contributing guide
• I agree to follow this project's Code of Conduct

[claremacrae]

Thank you for this!

I see you've force-pushed already, so I won't start reviewing yet, as any draft comments are invalidated (disconnected from the code) by force pushes...

So for now I'll just have a quick experiment on my Mac to see what the chosen Emoji looks like.

Please let me know when it's stable for a day or so, and I'll start reviewing.

[claremacrae]

PS For future reference - I would definitely recommend that you create a branch for PRs in future, rather than pushing from the default branch.

It will be easier for you and for maintainers.

[sonarqubecloud]

Quality Gate passed

Issues
11 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[claremacrae]

@Drezil I remain grateful for this contribution, but I am getting a little concerned about the size of this PR, before I have had a chance to review and give feedback on the initial code.

There are things needing to be improved about the design of the first layer - the storage, reading and writing of durations - and the behaviour of the Duration class.

The more code you add above the initial implementation of that layer:

• the more re-working there will be of the layers above
• the longer it will take me to review the code
• the more changes you will need to make
• the longer the process will take, and the more likely there will be be to have mergers conflicts to have to deal with.

Please do not add any more layers until you have let me know that the functionality you have now pushed is ready for review, and we have finalised what it looks like.

Thank you again for all your work.

[claremacrae]

Yes, reflecting on this, the design decisions about the lower layer will affect some aspects of the desired behaviour of the higher layers.

So, when you say the code added in the initial commit is ready review, i will first do an initial review of that code.

Once that has settled down, I'll then review searching/sorting/grouping.

[claremacrae]

Whilst I'm thinking about reviews, a general comment about how review Conversations are used in the project:

FYI I use the "conversation resolved" facility to mean that any discussion is completed and/or requested changes have been made and reviewed.

This enables me to keep track of what remains, whereas if the contributor marks conversations as being resolved, all discussion is hidden by github and it is easy for me to miss comments I needed to read, or changes I needed to review....

So in summary, as you respond to any review comments, please do leave a note to say when things have been done - but just please don't mark conversations as resolved - thanks in advance.