feat: refactor WebSocket

[Nerivec]

• feat: refactor WebSocket to use plain/optimized logic (no dependency)
  • optimized rendering
  • better handling of multi-instance
  • no React context
• feat: add frontend WebSocket health data in Settings>Health
• feat: refactor token auth to support single & multi instance, including separate tokens for separate instances

@Koenkk I won't merge this until after Sep release since it needs a decent amount of testing, but when you have some time, if you can review the new WebSocketManager class 👍

CC: @ams2990 @thargy

[Copilot]

Pull Request Overview

This PR refactors the WebSocket handling from using the react-use-websocket library to a custom plain/optimized WebSocketManager class. The refactor improves performance through better batching, removes React context dependencies, and adds WebSocket health metrics to the Settings > Health page.

Key Changes

• Complete replacement of React context-based WebSocket implementation with a singleton WebSocketManager
• Removal of react-use-websocket dependency and related hooks
• Addition of WebSocket health monitoring and metrics display in Settings > Health

Reviewed Changes

Copilot reviewed 41 out of 42 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/websocket/WebSocketManager.ts	New singleton WebSocket manager with optimized batching and health metrics
src/store.ts	Added WebSocket metrics interface and store actions for connection state tracking
Multiple component files	Removed React context usage and replaced with direct sendMessage imports
src/components/settings-page/tabs/Health.tsx	Added WebSocket health metrics display section
src/Main.tsx	Simplified initialization to use singleton manager instead of context provider
package.json	Removed react-use-websocket dependency

[ams2990]

@Nerivec happy to test this whenever it's ready. Just let me know.

[thargy]

Did a pull and can't see any obvious issues.

[Nerivec]

This should now be available in standalone edge. @ams2990 @thargy if you can give it a thorough testing (ideally in both multi and single to be sure no awkward behavior change occurs).

[crowbarz]

Does the new webproxy code require both standalone windfront edge AND z2m dev deployed on the z2m instances? It currently doesn't work for me with USE_PROXY enabled with z2m latest deployed.

In my setup, the z2m is behind an nginx instance configured to proxy the UI and API. I have created an additional HTTP server, without SSL, for the proxy. I have verified with wget from within the standalone windfront container that the container is able to fetch / successfully through the HTTP proxy, and generate an error log as expected when fetching /api.

This configuration works fine without USE_PROXY set, with both windfront 2.1.0 and edge. But I want to use USE_PROXY so the connections are proxied by windfront standalone, so I can add an ACL to the nginx to prevent direct end user connections to the z2m instances.

[Nerivec]

WindFront 2.1.0 or current edge should work fine with either Z2M 2.6.1 or 2.6.1-dev.
The only time this will break is if a new feature is introduced on Z2M side, and support is added in the UI (that part of the UI would require the new feature on Z2M side). Note that these versions will be clearly identified in the release notes so users are aware.

I'm not sure I have a good understanding of your setup. I'm also not sure of the proxying you're describing with built-in and standalone.
Some notes in the meantime, if it can help:
The docker container is a basic nginx:alpine-slim with the WindFront distribution files added to it.
USE_PROXY proxies the WebSocket connection of the Z2M instance. The nginx configuration can be seen here.
Complex hostnames/paths (special characters, etc.) could create problems due to how the proxying is implemented (passed as path); best to use simple hostnames (and paths if any). If anyone knows of a better way to do this, feel free to PR.
The serving of the built-in frontend can also be disabled in the Z2M instance (only the WebSocket remains).
It was tested pretty well with systems like Cloudflare tunneling or NabuCasa cloud, I don't expect the refactor would change any of this (it was just about removing the library wrapper and optimizing for the Z2M use-case). Granted, a bug could have been introduced 😅 but there has not been any feedback to suggest this yet (and the HA add-on requires this to work internally).

[ams2990]

This should now be available in standalone edge. @ams2990 @thargy if you can give it a thorough testing (ideally in both multi and single to be sure no awkward behavior change occurs).

Sorry for the delay -- I've been away and just got back yesterday. Initial testing looks good, I'm not observing any disconnects/reconnects. I'll leave developer tools open for a few hours to be sure.

[ams2990]

After some delay, I did observe disconnects and reconnects. Is there any data I can give you?

[Nerivec]

What kind of "delay" are we talking about? Does it keep working if you keep using the UI for that same amount of time (no out of focus, no tab switching, no minimizing, no stillness, etc.)? Is it the same delay if you try to reproduce? Is there a "reason" in the dev tools console logs for the close/error?