Fix a couple things in Typescript client #13863
Conversation
BrennanConroy
requested review from
analogrelay,
halter73 and
mikaelm12
as code owners
|
I assume: |
| @@ -608,7 +608,7 @@ export class TransportSendQueue { | |||
| offset += item.byteLength; | |||
| } | |||
|
|
|||
| return result; | |||
| return result.buffer; | |||
There was a problem hiding this comment.
The getDataDetail method which prints the info I put in the summary
There was a problem hiding this comment.
Interesting that the type checker didn't catch this.
There was a problem hiding this comment.
ArrayBuffer is a weird type. It has basically no public members, you have to wrap it in a view like Uint8Array. It's possible that, because of that, the result object technically does adhere to the ArrayBuffer interface (structurally, since that's all TS actually cares about).
Short answer: Type checker be weird
BrennanConroy
force-pushed
the
brecon/fixups
branch
from
5b80971 to
deb6e79
Compare
|
Finally got around to adding a test for this |
BrennanConroy
force-pushed
the
brecon/fixups
branch
from
deb6e79 to
df57274
Compare
|
Ping reviewers, this is ready |
| @@ -475,7 +475,7 @@ export class HttpConnection implements IConnection { | |||
| } | |||
|
|
|||
| if (this.connectionState === ConnectionState.Connecting) { | |||
| this.logger.log(LogLevel.Warning, `Call to HttpConnection.stopConnection(${error}) was ignored because the connection hasn't yet left the in the connecting state.`); | |||
| this.logger.log(LogLevel.Warning, `Call to HttpConnection.stopConnection(${error}) was ignored because the connection is still in the connecting state.`); | |||
There was a problem hiding this comment.
It would be better throw rather than no-op and log a warning if stopConnection is called while the connection is in the connecting state. HubConnection should await any start tasks in stop() and protect us from this actually occurring.
There was a problem hiding this comment.
Are you wanting me to change that behavior in this PR?
There was a problem hiding this comment.
If it's not too risky, yes. I don't want to have to spin a new PR for some code cleanup. If it causes a bunch of tests to fail, or you feel it's risky, we can make it another PR.
Before:
Trace: (WebSockets transport) sending data. .After:
Trace: (WebSockets transport) sending data. Binary data of length 3.TODO: Add a test for the "sending data" string.