Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose DOM WebSocket events close, error, open on WebSocketClient #2538

Open
davisford opened this issue Feb 16, 2024 · 0 comments · May be fixed by #2902
Open

Expose DOM WebSocket events close, error, open on WebSocketClient #2538

davisford opened this issue Feb 16, 2024 · 0 comments · May be fixed by #2902
Labels
enhancement Feature requests or improvements

Comments

@davisford
Copy link

Feature Request

Description of Problem:

The class WebSocketClient which is exposed through the perspective.websocket(url) function has the following interface:

https://github.com/finos/perspective/blob/master/packages/perspective/index.d.ts#L199-L204

    export class WebSocketClient {
        open_table(name: string): Promise<Table>;
        terminate(): void;
        initialize_profile_thread(): void;
        send(msg: unknown): void;
    }

The standard DOM WebSocket class allows the client to attach listeners to the WebSocket for events such as close, error, open, message. WebSocketClient attaches handlers for these events, but does not expose the events to the consumer; as such, if the websocket gets disconnected, we have no way of knowing or dealing properly with it. Then, if we try to send on the perspective.websocket a runtime error is triggered and it is not an ideal situation to deal with or code against. I would like to propose that the WebSocketClient allow the client to add its own event handlers, at least for 3/4 events... something like (probably botched TS syntax below, but you get the idea):

export class WebSocketClient {
   addEventListener(string<"close" | "open" | "error">, CloseEvent | Event);
   // other existing methods
}

Potential Solutions:

The only drawbacks I see are if the WS is to be recycled, before it is nil'd out, all handlers should be removed.

Adding this would allow us to better manage how we interact with the state -- given we'll be notified of what the current state of the websocket is at any given moment.

@texodus texodus added the enhancement Feature requests or improvements label Jan 23, 2025
@texodus texodus linked a pull request Jan 23, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests or improvements
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants