hs-client: move all websocket calls under .ws namespace. #886
Conversation
nodech
added
wallet
| @@ -420,20 +420,20 @@ describe('Node Rescan Interactive API', function() { | |||
| beforeEach(async () => { | |||
| client = nodeCtx.nodeClient(); | |||
|
|
|||
| await client.open(); | |||
| await client.ws.open(); | |||
There was a problem hiding this comment.
IMHO, consumers should not know about this.
When I'm using client, I want it to "open" and start doing whatever it needs to do. I don't need to know its internal structure. I don't want to know about ws. client is the interface I'm dealing with.
There was a problem hiding this comment.
Then you can't be sure if call to getHashes is ws call or not, can't figure out whether you need open at all or not.
Currently, there are no conflicting calls, that have both HTTP and WS calls. But there are several use cases for example getHeader - It can be requested as an HTTP, but wallet client or anything that needs stateful synchronized communication will rather use WS variation.
open/close are both on client and WSClient, as WSClient is basically a namespace, not a separation (All methods like hook, call, bind, fire are both on WSClient as wall as on Client. But moving out methods to me makes client side code more readable and easier to make judgment if you should call .open and whether it depends on an OPEN connection.
There was a problem hiding this comment.
You don't need to .open for majority of calls, RPC, HTTP. So there's no reason for any of those to have additional WS connection.
This makes it easier to reason about the calls. It becomes more explicit - what's going on, whether you need to call
.openfor a method call to work or not etc.bindings and etc, other than methods themselves, could also work on the
clientas they were. But it's recommended to use.ws, makes it easier to read.