hudson-newey commented 9 months ago

Implement Date/Time components

With the functionality of the date/time components now complete, we should implement them on the relevant pages to standardize formatting and localization.

This fixes a common and re-occuring point of user friction.

Changes

Remove toRelative pipe and associated tests
Migrates batch download table to use baw-zoned-datetime and baw-duration
The audio recordings list page now uses baw-duration for the "duration" column
The harvest list page now uses localized baw-datetime for the "created" column
The completed Harvest page now uses baw-duration for recording duration in the table
- Now uses baw-zoned-datetime (localized to site timezone) for "recorded" column
Annotation import pages (list & details) now use localized baw-datetime for "Created At" column
"My-annotations" page now uses the baw-time-since component for the "last updated" column
Event summary report now uses localized date/time component (baw-datetime) for generated date/time
- Now uses baw-duration for search range table
user-badge (created by xyz, updated by xyz, x time ago widget in menu bar) now uses baw-time-since
The site details page "This site contains recordings from abc to xyz" has been replaced by baw-zoned-datetime
The recent annotations component (found on the statistics page) now uses baw-time-since
Recent audio recording components (found on the statistics page) now use the baw-duration component for the "Duration" column
- Now uses the baw-time-since component for the "Uploaded [at]" column
The abstract model details page (audio recording details page now checks for Duration and DateTime types and formats them correctly using the baw-datetime and baw-duration components)
- DateTime is formatted in a localized date/time using baw-datetime (since this is predominantly used for "created at" fields and it retains the existing behavior)
- Durations are formatted in ISO8601 format I’m unsure this is correct, but it is the existing behavior. Perhaps we should use sexagesimal??
Add date/time test helper to standardise relative durations & date/time formats in tests
Updated unit & integration tests for the above
Removed the test that asserted the download table date/time tooltip was correct (this is now handled by the date/time components themselves)

Bug fixes

The tooltips on the Harvest statistics component is currently broken (due to infinite re-rendering on hover). This has now been fixed
The abtract-template.component.ts added whitespace before and after the datetime. This lead to incorrectly formatted documents and has been fixed

Problems

None

Issues

Fixes: #345 Fixes: #346

Visual Changes

The "created by" and "updated by" shields widget (in the menu bar) now uses the two largest units (to keep consistent with the rest of the relative duration formats in the website)

Old Format

New Format

The audio recordings page now shows fractional seconds

Old Format

New Format

Harvest ETA component now uses the `<baw-time-since>` and `<baw-duration>` components

This means that I have had to re-order some words above the progress bar

Old Format

New Format

This also removes an additional RxJS observable (potentially improving performance)

The "My Sites" page now uses the two largest units in the "Last Modified" column

Old Format

New Format

Recent annotations and recent audio recordings now show the two largest units

Old Format

New Format

The audio recording details page has new changed date/time formats

Old Format

New Format (amended)

Unshown visual changes

All implementation of the date/time, duration, and time-since components have their underline styling indicating that there is a tooltip on hover. See previously approved #2096 for underline styling

Final Checklist

[x] Assign reviewers if you have permission
[x] Assign labels if you have permission
[x] Link issues related to PR
[x] Ensure project linter is not producing any warnings (npm run lint)
[x] Ensure build is passing on all browsers (npm run test:all)
[ ] Ensure CI build is passing
[x] Ensure docker container is passing (docs)

github-actions[bot] commented 9 months ago

Size Change: +360 B (0%)

Total Size: 3.01 MB

Filename	Size	Change
`dist/workbench-client/browser/main-V4H2UQGM.js`	0 B	-1.07 MB (removed)	🏆
`dist/workbench-client/server/main.js`	1.87 MB	+256 B (0%)
`dist/workbench-client/browser/main-STQ7JKIV.js`	1.07 MB	+1.07 MB (new file)	🆕

ℹ️ View Unchanged

| Filename | Size | | :--- | :---: | | `dist/workbench-client/browser/assets/environment.json` | 555 B | | `dist/workbench-client/browser/index.html` | 4.71 kB | | `dist/workbench-client/browser/manifest.json` | 150 B | | `dist/workbench-client/browser/polyfills-C5CKP5CH.js` | 12.3 kB | | `dist/workbench-client/browser/styles-UNSEPFNK.css` | 39.4 kB | | `dist/workbench-client/server/776.js` | 4.2 kB |

_{compressed-size-action}

github-actions[bot] commented 9 months ago

Unit Test Results

        6 files         6 suites 8m 1s :stopwatch: 23 154 tests 22 638 :heavy_check_mark: 516 :zzz: 0 :x: 23 376 runs 22 860 :heavy_check_mark: 516 :zzz: 0 :x:

Results for commit 71c1f516.

:recycle: This comment has been updated with latest results.

atruskie commented 9 months ago

For this case we can probably just add a (<baw-datetime-since ...></baw-datetime-since>) afterwards to achieve a similar effect to what was there.

hudson-newey commented 9 months ago

For this case we can probably just add a (<baw-datetime-since ...></baw-datetime-since>) afterwards to achieve a similar effect to what was there.

My hesitation about this format was that we would have two tooltips that shouw the exact same information (one for the baw-datetime and one for the baw-time-since).

However, by adding a hasTooltip input signal to the abstract-template.component, we are able to conditionally hide the baw-time-since tooltip (since it give the same information as the baw-datetime tooltip)

atruskie commented 9 months ago

For this case we can probably just add a (<baw-datetime-since ...></baw-datetime-since>) afterwards to achieve a similar effect to what was there.

My hesitation about this format was that we would have two tooltips that shouw the exact same information (one for the baw-datetime and one for the baw-time-since).

However, by adding a hasTooltip input signal to the abstract-template.component, we are able to conditionally hide the baw-time-since tooltip (since it give the same information as the baw-datetime tooltip)

I don't think we need to worry honestly. The tooltips add context to the text they wrap. They're not on by default.

If we really wanted to solve this we might add another datetime control or option to show date and time-since in one component. But as it stands we have exactly one example so that would be premature optimization - as would be adding an option to hide the tooltip

QutEcoacoustics / workbench-client