Adapting TS-client to work with non-level-2 xhr #744
Conversation
| @@ -168,6 +168,12 @@ export class LongPollingTransport implements ITransport { | |||
| connect(url: string, requestedTransferMode: TransferMode): Promise<TransferMode> { | |||
| this.url = url; | |||
| this.shouldPoll = true; | |||
|
|
|||
| let actualTransferMode = | |||
There was a problem hiding this comment.
I think you meant to use this
There was a problem hiding this comment.
I will remove this code.
This is a leftover of my failed attempt to send MessagePack over non-level-2 xhr. This won't work because the server assumes it knows transfer modes a transport supports. I opened #742 for this.
| if (pollXhr.response) { | ||
| console.log(`(LongPolling transport) data received: ${pollXhr.response}`); | ||
| this.onDataReceived(pollXhr.response); | ||
|
|
moozzyk
force-pushed
the
pawelka/ts-node
branch
2 times, most recently
from
509f304 to
17f13c7
Compare
|
🆙📅 |
|
Looks clean but I still don't want to require polyfills to work with node. This is fine for the alpha |
|
|
||
| if (requestedTransferMode === TransferMode.Binary && (typeof new XMLHttpRequest().responseType !== "string")) { | ||
| // This will work if we fix: https://github.com/aspnet/SignalR/issues/742 | ||
| throw new Error("Binary protocols over XmlHttpRequest not implementing advanced features not supported."); |
There was a problem hiding this comment.
nit: Binary protocols over XmlHttpRequest not implementing advanced features are not supported.
|
We have an issue for not using polyfills on node. This is post-alpha. Note that this change is a bit more general - it makes signalr client work on browsers that don't support level 2 features (looks like only opera mini falls in this category though) |
Opera mini 🤣 |
moozzyk
force-pushed
the
pawelka/ts-node
branch
from
17f13c7 to
4196f98
Compare
moozzyk
force-pushed
the
pawelka/ts-node
branch
from
4196f98 to
1964e36
Compare
Also exporting MessagePackHubProtocol