Workout Creator Integration/Standardization

[DXCanas]

First off, thank you @NickOldfield for this contribution! 🎉 The workout goal feature is a great addition to the UI, and we (all users as well as the excellent maintainers) really appreciate you taking the time to implement it. This was clearly a thoughtful piece of work.

What this PR does

This PR refactors the contributed workout goal popup from workout-bar.js into the project's Lit component architecture. The functionality remains identical—users can still click Distance/Timer/Calories tiles to set workout goals with the same increments and behavior.

Why the refactor?

While the original implementation worked, integrating it into the existing component patterns should help with long-term maintainability. Here's what changed and why:

1. Component architecture alignment

• Before: Vanilla DOM manipulation with direct document.createElement() calls
• After: Proper Lit component (<workout-dialog>) extending AppElement
• Why: The other UI components use Lit's reactive property system. This makes the code more maintainable and consistent with components like SettingsDialog, DashboardToolbar, etc.

Even if we eventually drop lit as a framework, the standardization of each component would make it much easier to port.

2. Event flow standardization

• Before: window.dispatchEvent() bypassing the component tree
• After: Bubbling composed events (bubbles: true, composed: true) that traverse shadow DOM
• Why: The architecture (ideally) uses "properties down, events up" — child components communicate with parents via bubbling events. Window-level events break this pattern and make it harder to reason about data flow.

3. Centralized WebSocket communication

• Before: This feature creating was its own WebSocket connection
• After: All commands route through handleAction() in app.js
• Why: The app uses a single shared WebSocket connection. This, along with the centralized handleAction pattern used by other features (reset, upload, shutdown, etc.), simplifies things with standards.

4. Dialog reuse

• Before: Custom modal implementation
• After: Uses existing <app-dialog> component
• Why: There's already a dialog component with proper theming, keyboard handling, and accessibility. Reusing it ensures consistent UX and reduces code duplication. Future improvements to the dialog component will benefit all consumers 😄

5. Theme compatibility

• Before: Hardcoded colors that didn't work with true-black theme
• After: CSS variables (--theme-font-color, --theme-widget-color, etc.)
• Why: Personal testing revealed visibility issues using the True Black theme. Using CSS variables ensures the dialog adapts to all theme variants.

6. Future compatibility

• Why now: There's upcoming work on the retile-mode branch (commit 7bfbb31) that adds interactive dashboard customization. This refactor places dialog management on PerformanceDashboard using the same pattern (_dialog state + connectedCallback listeners), which should make that merge nearly conflict-free.

What stayed the same

✅ All 3 workout types (distance, time, calories)
✅ All increment values and formatting
✅ User-facing behavior and UX
✅ WebSocket message format (updateIntervalSettings)

Technical changes

• New: app/client/components/WorkoutDialog.js — Lit component with reactive state
• Modified: app/client/components/PerformanceDashboard.js — Dialog host with event listener
• Modified: app/client/lib/app.js — Added updateIntervalSettings to handleAction
• Modified: app/client/store/dashboardMetrics.js — Bubbling events instead of window events
• Removed: app/client/workout-bar.js — Replaced by WorkoutDialog component

Relevant Notes

• Workout configs and session times #216
• Frontend Data Layer Refactor #175
• Frontend Component-Level Refactors #179

---

Again, huge thanks for the contribution!

[Abasz]

@JaapvanEkris I will test this new, can we include it in 0.9.7 please?

[JaapvanEkris]

@JaapvanEkris I will test this new, can we include it in 0.9.7 please?

No problem. 0.9.7 is closing Sunday evening, and this seems a good idea to include. Can wait a day or two if needed, but Abasz also wants to move to the new CI/CD pipeline.

For me 0.9.7 will close with a large addittion to the fit-files. End this year RowsAndAll will close (the only site capable of showing all our metrics) and intervals.icu will take over (RowsAndAll's owner is porting the functionality) As that creates an externally imposed deadline to keep data flowing, I want to make sure that we are 99% ready for that move now, as it otherwise would put a lot of pressure on 0.9.8 to be ready when RowsAndAll really pulls the plug. The FIT definition had a lot of moving parts on all side, but it seems to have come together yesterday (already got a working prototype).

[Abasz]

I made some changes this is how this looks like:

Small screen

Button hover and click:

Unless @DXCanas or @NickOldfield has any comments this can be merged tomorrow.

[DXCanas]

I made some changes this is how this looks like:

Small screen Button hover and click: Unless @DXCanas or @NickOldfield has any comments this can be merged tomorrow.

Always a fan of less wrappers, personally. Lgtm 😊

[NickOldfield]

It looks good! Thanks for fine tuning and the improvements.

[JaapvanEkris]

Guys, one kind of bug: when you set a time/distance/calorie target, the large number line has a unit (m/m/kcal), but this unit is also noted below it. I propose to remove it from the number-line, and onlu show it below the number line,

[DXCanas]

Guys, one kind of bug: when you set a time/distance/calorie target, the large number line has a unit (m/m/kcal), but this unit is also noted below it. I propose to remove it from the number-line, and onlu show it below the number line,

Ha, I just caught that while trying it out yesterday during a workout. I’m running around most of today but I’ll try and get that in before EOD

[DXCanas]

@JaapvanEkris Actually, I'm seeing the reasoning

there's logic in place to change between "m" and "k" once the workout goes hits 10k:

https://github.com/JaapvanEkris/openrowingmonitor/pull/225/changes#diff-9dd1b4b472a6aa49669206847857bdef90841ebc196f0a86fd1278076755a8d9R22

If we want to keep that logic, we could just remove the "m" and keep "metres". Or we can just remove "metres" and assume that the user knows what they're signing up for (which. I think is a fair assumption).

Going to stick with "metres" to keep the standard going -- kcal and minutes don't have units in the number display.

[JaapvanEkris]

@JaapvanEkris Actually, I'm seeing the reasoning

there's logic in place to change between "m" and "k" once the workout goes hits 10k:

In rowing people generally talk about meters. Even on large distances like the marathon or the half century, it is still displayed in meters by design. Our GUI starts switching to kilometers above 99,999.5 meters....

[DXCanas]

Yeah — so the unit below is always going to say meters below the number line, as described. And the metric square will also always say it in raw meters.

I think the “k” behavior was intended for visual space saving for kcal or when the number gets up there (100,000m vs 100k)

You would rather leave it as the raw number no matter what?

[JaapvanEkris]

You would rather leave it as the raw number no matter what?

That is the behaviour of every monitor on the market today, including ORM. We only start trimming at 100K as it physically doesn't fit the tile.