From ce98114704a10fe49f8bbe2c0fa4730c85f1a936 Mon Sep 17 00:00:00 2001 From: Stephen Halter Date: Fri, 14 Jun 2019 14:18:54 -0700 Subject: [PATCH] Update javascript-client.md to reflect IRetryPolicy changes (#12875) --- aspnetcore/signalr/javascript-client.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/aspnetcore/signalr/javascript-client.md b/aspnetcore/signalr/javascript-client.md index befde835cb..dbe025dcff 100644 --- a/aspnetcore/signalr/javascript-client.md +++ b/aspnetcore/signalr/javascript-client.md @@ -202,9 +202,9 @@ If the second reconnect attempt fails, the third reconnect attempt will start in The custom behavior then diverges again from the default behavior by stopping after the third reconnect attempt failure instead of trying one more reconnect attempt in another 30 seconds like it would in the default configuration. -If you want even more control over the timing and number of automatic reconnect attempts, `withAutomaticReconnect` accepts an object implementing the `IReconnectPolicy` interface, which has a single method named `nextRetryDelayInMilliseconds`. +If you want even more control over the timing and number of automatic reconnect attempts, `withAutomaticReconnect` accepts an object implementing the `IRetryPolicy` interface, which has a single method named `nextRetryDelayInMilliseconds`. -`nextRetryDelayInMilliseconds` takes two arguments, `previousRetryCount` and `elapsedMilliseconds`, which are both numbers. Before the first reconnect attempt, both `previousRetryCount` and `elapsedMilliseconds` will be zero. After each failed retry attempt, `previousRetryCount` will be incremented by one and `elapsedMilliseconds` will be updated to reflect the amount of time spent reconnecting so far in milliseconds. +`nextRetryDelayInMilliseconds` takes a single argument with the type `RetryContext`. The `RetryContext` has three properties: `previousRetryCount`, `elapsedMilliseconds` and `retryReason` which are a `number`, a `number` and an `Error` respectively. Before the first reconnect attempt, both `previousRetryCount` and `elapsedMilliseconds` will be zero, and the `retryReason` will be the Error that caused the connection to be lost. After each failed retry attempt, `previousRetryCount` will be incremented by one, `elapsedMilliseconds` will be updated to reflect the amount of time spent reconnecting so far in milliseconds, and the `retryReason` will be the Error that caused the last reconnect attempt to fail. `nextRetryDelayInMilliseconds` must return either a number representing the number of milliseconds to wait before the next reconnect attempt or `null` if the `HubConnection` should stop reconnecting. @@ -212,8 +212,8 @@ If you want even more control over the timing and number of automatic reconnect const connection = new signalR.HubConnectionBuilder() .withUrl("/chatHub") .withAutomaticReconnect({ - nextRetryDelayInMilliseconds: (previousRetryCount, elapsedMilliseconds) => { - if (elapsedMilliseconds < 60000) { + nextRetryDelayInMilliseconds: retryContext => { + if (retryContext.elapsedMilliseconds < 60000) { // If we've been reconnecting for less than 60 seconds so far, // wait between 0 and 10 seconds before the next reconnect attempt. return Math.random() * 10000; @@ -245,7 +245,7 @@ The following code demonstrates a typical manual reconnection approach: [!code-javascript[Reconnect the JavaScript client](javascript-client/sample/wwwroot/js/chat.js?range=28-40)] -A real-world implementation would use an exponential back-off or retry a specified number of times before giving up. +A real-world implementation would use an exponential back-off or retry a specified number of times before giving up. ## Additional resources