Improve preferences interface - hours worked & break time fields #915
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue
Closes #914
Context / Background
Hello, I am a first time contributor and I would greatly appreciate any feedback - please let me know if you have any suggestions! Thank you.
To improve user experience it is possible to utilize an HTML combo box in the preferences interface, which provides the user with selected options for hours worked and break times, while also preserving their ability to enter custom values or more obscure time durations. Currently, the user has to somewhat infer that they must enter a duration in the format HH:MM specifically, though they are currently notified when their entered values do not meet the required format.
What change is being introduced by this PR?
Originally my intent was to add the capability of the hours worked and break time fields to take custom inputs in formats other than HH:MM, such as a single digit hour amount or a decimal amount (8.5 converting to 08:30). I was unable to trace inputs and their respective validity checks to a specific function in the code, and I assume this is an Electron or JQuery feature which I am unfamiliar with. An easy HTML solution I was able to implement is to use combo boxes in /src/preferences.html, which act as a dropdown while preserving the ability to enter custom values. This involves simply specifying "list" in the relevant HTML input lines and specifying a datalist which contains any template/selectable values. Background on this functionality: https://www.educba.com/combobox-in-html/ . The dropdown, however, overlaps the "Please match the requested format" alert and this could be further improved upon.
How will this be tested?
The Jest test suites show no changes in coverage, rendering, updating of variables, or any other observable field. Manual testing also shows that both when selecting a value from the dropdown field or entering a value into the text box, that value passes validity checks and is saved upon closing the preferences interface.