refactor: extract label generation for Edit Task modal

[ilandikov]

Description

Sorry for a big PR =) I can split it into several ones if needed.

• remove CSS class accesskey-first and unify access key declaration with accesskey class
• remove HTML elements declaring access keys from the modal without access keys
  • Somehow they were still in the <label> elements O_o
  • They were not present in <input> elements which inhibited the access keys
• extract editTaskLabelContent() function to generate the label content
  • use it everywhere except priority (there the content is different and linked with CSS styles, so no gain for now)
• for dependencies and dates, move <label> to <Dependency> and <DateEditor> component respectively

Motivation and Context

• Move HTML code generation inside the components (for <Dependency> and <DateEditor>)
• Prepare to extract Svelte components (for other Task fields/future components)

How has this been tested?

Unit test made possible with thanks to a previous PR with @claremacrae

Manual test at the end of the refactoring:

• Verify that access keys are not working when disabled in Settings
• Verify that each access key focuses its field in the modal when enabled in Settings

Types of 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)

Checklist

• My code follows the code style of this project and passes yarn run lint.
• My change has adequate Unit Test coverage.
  • Couple of commits in CSS code make me say no to this

Terms

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

[ilandikov]

Added jsdocs and refactored a bit =) No more pushes, ready for review =)

[claremacrae]

Hi @ilandikov,

I started doing a review and then saw you're still pushing.

That's absolutely fine - could you just let me know when it's ready for review please?

[claremacrae]

Hi @ilandikov,

I started doing a review and then saw you're still pushing.

That's absolutely fine - could you just let me know when it's ready for review please?

Cancel that - I've just seen your comment...

[claremacrae]

Thanks... I've given this a once over, but it's too big to review in one evening. Since it exists, I don't think there's any point you doing it all over again, and I would likely have the same comments...

I'll review my draft comments on Tuesday, or worst case, Wednesday evening, and get back to you...

[ilandikov]

The trajectory of this PR is quite linear, so splitting it into several PR is pretty straightforward. Are you sure you don’t want me to do this?)

or you can see it this way - the only functionality I’m touching are the access keys. They work as expected, so the main questions is “is the state of the code better now?”

[claremacrae]

The trajectory of this PR is quite linear, so splitting it into several PR is pretty straightforward. Are you sure you don’t want me to do this?)

or you can see it this way - the only functionality I’m touching are the access keys. They work as expected, so the main questions is “is the state of the code better now?”

OK, that's a helpful comment.

In that case, I'll go ahead and submit my comments after a first half hour or so of reviewing just on GitHub...

Then you'll have time to address anything you care to, and my next run through the code might be a little easier...

[claremacrae]

Thank you for this.

Here are some thoughts after a first read through...

[claremacrae]

Thanks!

[ilandikov]

Thanks a lot for your review! Let's discuss the details this WE