WebSocketCtor in WebSocketSubject must allow more params in new instance
See original GitHub issueRxJS version: v5.4.3
Code to reproduce: Not a bug but an ask for enhancement
Expected behavior:
WebSocketCtor
must allow all options that we can have in WebSocketClient
Missing options can be passed inside WebSocketSubjectConfig like url
and protocol
Actual behavior:
Only two options are allowed in WebSocketCtor
Issue Analytics
- State:
- Created 6 years ago
- Comments:10 (4 by maintainers)
Top Results From Across the Web
"ReferenceError: WebSocket is not defined" when using RxJs ...
In my app, I'm using websocket communication using RxJs. More specifically, I'm, using WebSocketSubject and webSocket in my angular universal 6.
Read more >WebSocketSubjectConfig - RxJS
It defines a set of properties to provide custom behavior in specific moments of the socket's lifecycle. When the connection opens we can...
Read more >Add Real-time Capability to Your Web App with RxJS ...
Let's connect. To make a connection to an existing WebSocket endpoint, we need to create an instance of WebSocketSubject .
Read more >Observable | RxJS API Document - ReactiveX
Combines multiple Observables to create an Observable whose values are calculated ... Remember that Error object passed to callback does not have to...
Read more >eggheadio-projects/step-by-step-async-javascript-with-rxjs: null
If there are more parameters (third and so on), * Observable will emit an ... WebSocketCtor) { throw new Error('no WebSocket constructor can...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@benlesh The
WebSocketCtor
could simply be a customizable function that returns an instance of a WebSocket client instead of a constructor. That way we would be able to completely take control of what options are passed. Currently it is for instance not possible to set custom headers for the handshake, etc.I see. Hmmm…
nodejs-websocket
was more somethign I was suggesting as a polyfill for Node that doesn’t have WebSocket.Honestly, in the near future I’d like to take stuff like this and the AJAX stuff and move it to a DOM related package instead of in core.
I’m not sure how I feel about updating this library to support a non-standardized API from a third party. So I’m going to say my answer is “no” for now, but I’ll reopen the issue and allow others, like @kwonoj to comment.
Thank you for the suggestion!