feat: dynamic HTML page titles showing current page and subpages

[DennisGaida]

I didn't like the current page title especially with multiple Z2M tabs open and not knowing which one is what.

• New TitleUpdater component handles all title logic
• Removes hardcoded title, improving UX when tabbing between pages & bookmarking
• Page titles now display as 'Zigbee2MQTT - Page Name'
• Device detail pages show the device friendly name & current tab name: 'Zigbee2MQTT - Friendly Name - Tab Name'
• Group detail pages show the group friendly name with tab
• Settings pages show tab: 'Zigbee2MQTT - Settings - Tab'
• All tab names are properly capitalized and translated
• Route parameters are extracted from pathname (not useParams since component is outside Routes)

---

I did go through npm run check, npm run test:cov as well as npm run build and this change shouldn't break anything since all it does is set the page title.

[Nerivec]

See #276 for the reasons this was not done.

[DennisGaida]

I even like the suggestion of Z2M - better. As for discouraging multiple tabs: understood, but that doesn’t change that I sometimes open a device with CTRL-click to keep the the dashboard open and have the device on another tab.

I don’t believe that only by having dynamic HTML titles we are encouraging using multiple tabs.

[Nerivec]

I don’t believe that only by having dynamic HTML titles we are encouraging using multiple tabs.

In fact, a different title is only useful if you are using multiple tabs, which this is not designed work with (1 opened page = 1 connection instance). So, it could only encourage the use of multiple tabs, which would create tiny, impossible-to-fix sync/timing issues, confuse less technically-inclined users, and generate pointless issues for devs (I've had to repeat this enough times without it already..).
As mentioned before, the Z2M frontend should be viewed as an app, not a website, despite its access method.

[DennisGaida]

I fully understand and respect that the Z2M frontend is designed to be used as a single-instance app, not as a multi-tab website, and I’m not trying to encourage multi-tab usage.

My motivation for dynamic titles is much simpler: orientation. Even when I strictly use one tab (as intended), the browser tab title is still the primary place where users see where they are before they switch to it.

When the title is always "Zigbee2MQTT WindFront" (I personally also don't like that the frontends name is in the title, this is not information i want to see when switching to this tab/app), I frequently switch to the tab expecting one context (e.g. the dashboard) and land in another (e.g. logs or settings). Seeing "Zigbee2MQTT – Logs" or "Zigbee2MQTT – Settings" helps set expectations before focus changes, even with a single open instance.

In that sense, I’m treating the title like an app window title. Native apps commonly update their window title based on the current view, without implying that multiple instances are supported.

I understand if this still doesn’t align with the project’s UX philosophy—but I wanted to clarify that the goal isn’t multi-tab workflows, only better in-app orientation (or in-browser tab viewing).

[DennisGaida]

Wrong button - didn't want to close, since that is your decision.

[deviantintegral]

Z2M frontend is designed to be used as a single-instance app

I don't think that's clear to end users, and I suspect that many will have multiple tabs open through intent, or by forgetting to close them. Multiple tabs or windows is also core expectation of the web. I don't think I've ever used a web app that broke with multiple tabs, and in my experience Windfront has been perfectly fine!

Regardless, having unique page titles per URL is a core component for web accessibility, as mentioned by WCAG.

In cases such as Single Page Applications (SPAs), where various distinct pages/views are all nominally served from the same URI and the content of the page is changed dynamically, the title of the page should also be changed dynamically to reflect the content or topic of the current view.

Even in the single tab scenario, having descriptive titles helps users of all types so it would be great to see this addressed!

[Nerivec]

I don't think that's clear to end users

Definitely... unfortunately, there's no good way to make this explicit other than publishing a standalone app...

We have the "specific" behavior of having everything driven by a "live" websocket (publish, update, forget), unlike a traditional SPA that will use a database & co, where everything is neatly synced.
It does not break, but if you keep switching tabs, since you have multiple connections/stores, you eventually will see sync problems & co, stores won't match after some operations, etc..
I've had the case a few times before, it is a nightmare to debug, because of course, you don't know the user had multiple tabs opened 😅

I see the "app title"-only (which was same in previous frontend) as a "barrier" to this problem, but maybe I'm wrong...
I guess we can try, we can always revert if issues becomes unmanageable... Need to refactor this to use in-place static React <title> though, no need for an effect that generates this dynamically.

[DennisGaida]

So proud of my little component 😉, but if you think a static React <title> may work as well, that surely is simpler. I had problems extracting the "sub-titles" from the pages, but maybe I was just not versed enough. I can also try using static react.

In terms of multi-tabs (and out-of-scope of this PR), we could use something like a BroadcastChannel to mirror messages. Keep X WS conns open, but add a BC so that all tabs see the exact same messsage stream regardless of which conn received it first. Those messages could get a sourcetabId and bob's your uncle.
That would still mean multiple connections and there may be other problems with this, but it would reduce problems with divergence / missed messages.

[Nerivec]

I'll take a look if we can just use <title> when I have some time. Should be much lighter.