felangel / web_socket_client

A simple WebSocket client for Dart which includes automatic reconnection logic.
https://pub.dev/packages/web_socket_client
MIT License
150 stars 32 forks source link

feat: public connect fuction #41

Closed XanderD99 closed 3 months ago

XanderD99 commented 6 months ago

Description

Don't authomatically connect when websocket class is created, but instead expose the now private _connect function.

Additional Context

I have a usecase where I don't want the socket to connect the second it is created.

felangel commented 4 months ago

Hi @XanderD99 Can you provide more context regarding your use case? Couldn’t you delay creating the class until you need it or make it late?

XanderD99 commented 4 months ago

Well I accidentally already increased the scope of the PR that I made but, I initially just wanted to be able to keep the same instance of Websocket for a specific connection and connect it whenever I wanted to. Now I already updated to also expose a separate function called disconnect, which basically is a copy of close but doesn't close and cancel all streams.

Why was this something I would want is to not have to cancel all listeners and recreate then when disconnecting manually. It first came forwards when a feature in an app I was making was made to be able to manually test the websocket connect/disconnect.

Now due to design flaw in a websocket I am using, it is also just easier to disconnect and reconnect to prevent race conditions. Therefor a flow to manually disconnect and connect again without having to create a new instance of WebSocket seemed useful to me.

I also don't use it as final ws = WebSocket(...) but I extend your WebSocket implementation as base of my Client.

felangel commented 4 months ago

I also don't use it as final ws = WebSocket(...) but I extend your WebSocket implementation as base of my Client.

I believe you should already be able to achieve this without changing the public API. You can delay instantiating your Client until you want to establish a connection. In terms of disconnecting without canceling the underlying subscription/listeners, that seems like a work-around that is specific to your app and likely doesn't belong in the general-use library.

Now due to design flaw in a websocket I am using, it is also just easier to disconnect and reconnect to prevent race conditions.

Since it sounds like you're just working around poor design I'd prefer not to modify the public API of the library. Generally if you want to stop listening you can close the connection and re-establish a new connection later if you'd like.

XanderD99 commented 4 months ago

yes you may have a point there.

felangel commented 3 months ago

Closing for now since it doesn't appear like there are any actionable next steps. Feel free to file a new issue if this is still a problem and happy to continue the conversation 👍