Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support for specifying STUN server: frontend (3/3) (#1647)
Resolves #1460. Stacked on #1646, blocked on #1657 and tiny-pilot/tinypilotkvm.com#1053. This PR adds the UI for specifying a STUN server, and eventually makes the feature available to the end-user. → [Latest bundle off this branch](https://output.circle-artifacts.com/output/job/f2379490-a459-43d5-b1fb-ce009c971fcd/artifacts/0/bundler/dist/tinypilot-community-20231005T1841Z-1.9.1-27+3ff1062.tgz), for testing the entire PR stack. ## Demo https://github.com/tiny-pilot/tinypilot/assets/83721279/8108dcf2-1fe4-42d1-8c2a-4066cc669ad0 ## Notes - In contrast to the mockups in the ticket (e.g. [the latest one](#1460 (comment))), the proposed implementation here has a separate field for the host part and the port part of the STUN address. I realized that this simplifies a lot of things, because we don’t need to parse and split a unified address string (e.g. `stun.example.org:3478`), or serialize it again correctly. That would be especially tricky, since Janus supports IPv6, where the serialized format would look like e.g. `[12:c1:1832::c1:2]:3478`, so we can’t just naively split and join at the `:` character. - I separated the STUN input part into its own component, otherwise the `<video-settings-dialog>` would have become pretty large. - I debated whether to split off the entire “Advanced Settings” section, or just the STUN input. I eventually settled with the latter, because I felt it was conceptually more fitting, and I thought it would be the more granular approach, e.g. should we add more controls to the advanced settings in the future. I’m not married to it, though – I also think the entire `<video-settings-dialog>` component is borderline big anyway, so should we ever expand it further, it would probably be worth to consider a refactoring. - I had to [refactor (reverse) the CSS logic for showing/hiding the `.setting-...` classes](https://github.com/tiny-pilot/tinypilot/blob/e305ca104b54e485ee4e32876f1f8d181103b810/app/templates/custom-elements/video-settings-dialog.html#L30-L38). With the current implementation, it only allowed for `display: flex`, but with the new code, we also need `display: block` (on `.advanced-settings`). - Note that the `#stun-validation-error` is still part of `<video-settings-dialog>`, since validation errors are supposed to be “dialog-wide” errors, displayed at the bottom of the dialog, near the call-to-action button. If there were more inline / validation errors in the future, we’d also add them there, at top level. - One note about terminology: in the Janus config, the two address components are called [`server` and `port`](https://github.com/tiny-pilot/tinypilot/blob/0a03d2caf54aa083ef66c1606e28321f41aca781/debian-pkg/usr/share/tinypilot/templates/janus.jcfg.j2#L24-L25). I took over that terminology in the entire code, but in the UI I labelled the `server` fragment “Host”. To me, that’s technically more accurate, and since we already say “STUN Server” next to the dropdown button already, I thought “Server” might be confusing. I’m not sure there is a “right” answer here. We could otherwise also call it “Address”, but I feel that’s even broader. - The UI implementation has a few edge-cases with slightly unexpected/quirky behavior. We’d need to pay with more code and complexity to sort them out, though, and I felt that wouldn’t be worth it. Examples: - If you select “Custom” in the dropdown and then manually fill in the Google server details (`stun.l.google.com` + `19302`), then it would display the “Google” option the next time you open the dialog, and not the custom input fields. That’s because both ways look the same internally, and we’d need to maintain extra state to distinguish whether this was a custom input or one of the predefined selections. - If you select “Custom” and enter an invalid or incomplete address, and then choose “MJPEG” as streaming mode again, and then hit the “Apply” button, it still displays the STUN validation error. The reason is that the entire code around processing video settings is designed to always send and apply **all** values, regardless of what mode you eventually chose. <a data-ca-tag href="https://codeapprove.com/pr/tiny-pilot/tinypilot/1647"><img src="https://codeapprove.com/external/github-tag-allbg.png" alt="Review on CodeApprove" /></a>
- Loading branch information