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
Open

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

davisford opened this issue Feb 16, 2024 · 0 comments

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant