@anephenix/sarus - npm Package Compare versions

Comparing version 0.0.2 to 0.1.0

CHANGELOG.md

 # CHANGELOG
 
+### 0.1.0 - Sunday 10th March, 2019
+
+- Added a new feature: retryConnectionDelay
+- Updated documentation
+
 ### 0.0.2 - Sunday 3rd March, 2019
@@ -4,0 +9,0 @@

FUTURE.md

@@ -20,1 +20,4 @@ Scenario:
 - Introduce an exponential back-off strategy to Sarus in the near future.
+
+Note - there is a `retryConnectionDelay` option - perhaps this could be used to
+support the feature by passing a function that implements exponential back-off.

index.js

@@ -34,2 +34,3 @@ // File Dependencies
  * @param {number} param0.retryProcessTimePeriod - An optional number for how long the time period between retrying to send a messgae to a WebSocket server should be
+ * @param {boolean|number} param0.retryConnectionDelay - An optional parameter for whether to delay WebSocket reconnection attempts by a time period. If true, the delay is 1000ms, otherwise it is the number passed
  * @param {string} param0.storageType - An optional string specifying the type of storage to use for persisting messages in the message queue
@@ -47,2 +48,3 @@ * @param {string} param0.storageKey - An optional string specifying the key used to store the messages data against in sessionStorage/localStorage
       retryProcessTimePeriod,
+      retryConnectionDelay,
       storageType,
@@ -77,2 +79,9 @@ storageKey
     /*
+      This handles whether to add a time delay to reconnecting the WebSocket
+      client. If true, a 1000ms delay is added. If a number, that number (as 
+      miliseconds) is used as the delay. Default is false.
+    */
+    this.retryConnectionDelay = retryConnectionDelay || false;
+
+    /*
       Sets the storage type for the messages in the message queue. By default
@@ -106,2 +115,4 @@ it is an in-memory option, but can also be set as 'session' for
     // This binds the process function call.
+    this.reconnect = this.reconnect.bind(this);
+    this.connect = this.connect.bind(this);
     this.process = this.process.bind(this);
@@ -210,2 +221,3 @@ this.connect();
   connect() {
+    this;
     this.ws = new WebSocket(this.url);
@@ -216,2 +228,26 @@ this.attachEventListeners();
   /**
+   * Reconnects the WebSocket client based on the retryConnectionDelay setting.
+   */
+  reconnect() {
+    const self = this;
+    const { retryConnectionDelay } = self;
+    switch (typeof retryConnectionDelay) {
+      case 'boolean':
+        if (retryConnectionDelay) {
+          setTimeout(self.connect, 1000);
+        } else {
+          self.connect();
+        }
+        break;
+      case 'number':
+        setTimeout(self.connect, retryConnectionDelay);
+        break;
+      default:
+        throw new Error(
+          'retryConnectionDelay should be either a boolean or a number'
+        );
+    }
+  }
+
+  /**
    * Adds a function to trigger on the occurrence of an event with the specified event name
@@ -312,3 +348,3 @@ * @param {string} eventName - The name of the event in the eventListeners object
         if (eventName === 'close' && self.reconnectAutomatically) {
-          self.connect();
+          self.reconnect();
         }
@@ -315,0 +351,0 @@ };

package.json

 {
   "name": "@anephenix/sarus",
-  "version": "0.0.2",
+  "version": "0.1.0",
   "description": "A WebSocket JavaScript library",
@@ -5,0 +5,0 @@ "main": "index.js",

README.md

@@ -125,17 +125,9 @@ # Sarus
 
-The `connect` function is called immediately, and it will repeat this until it
-gets a `WebSocket` instance whose connection is open. The benefit of this is
-that there is no delay in re-establishing a WebSocket connection. The drawback
-is that it can end up submitting a lot of requests to re-establish a WebSocket
-conection, if say the WebSocket server is down for a few seconds, and there are
-a lot of browsers open on a page that all wish to connect to the server.
+The `connect` function is called immediately by default, and it will repeat
+this until it gets a `WebSocket` instance whose connection is open.
 
-In the case that you wish to implement your own reconnection strategy with say
-some exponential back-off applied (a time delay between reconnection attempts),
-you can disable the automatic reconnection strategy. You can do that by passing
-the `reconnectAutomatically` parameter to the `Sarus` class instance:
+If you do not want the WebSocket to reconnect automatically, you can pass the
+`reconnectAutomatically` parameter into the sarus client at the point of
+initializing the client, like the example below.
 
-There will be a plan to introduce an exponential back-off strategy to Sarus in
-the near future.
-
 ```javascript
@@ -148,5 +140,38 @@ const sarus = new Sarus({
 
-To create your own exponential backoff strategy, write a function and attach it
-to the `sarus` instance on the `close` event in the eventListeners parameter.
+#### Delaying WebSocket reconnection attempts
 
+When a connection is severed and the sarus client tries to reconnect
+automatically, it will do so without delay. If you wish to delay the
+reconnection attempt by a small period of time, you can pass a
+`retryConnectionDelay` parameter to the sarus client. If you pass `true`, then
+it will delay the reconnection attempt by 1000ms:
+
+```javascript
+const sarus = new Sarus({
+  url: 'wss://ws.anephenix.com',
+  retryConnectionDelay: true
+});
+```
+
+If you pass a number, then it will delay the reconnection attempt by that time
+(in miliseconds):
+
+```javascript
+const sarus = new Sarus({
+  url: 'wss://ws.anephenix.com',
+  retryConnectionDelay: 500 // equivalent to 500ms or 1/2 second
+});
+```
+
+**NOTE**
+
+Our recommendation is to enable this option by passing `true`. The reason for
+this is because we are seeing an issue where event listeners that were attached
+to closed WebSocket connections are not getting garbage collected in the
+web browser ([See GitHub issue: "Event listener garbage collection"](https://github.com/anephenix/sarus/issues/2)).
+
+Even though those event listeners will not be emitted (as they are attached to
+a severed WebSocket connection), they still exist in the web browser's memory.
+We are trying to identify the root cause of that issue, and resolve it.
+
 #### Attaching and removing event listeners
@@ -153,0 +178,0 @@

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

55067

increased by8.98%

Number of package files

18

increased by5.88%

Lines of code

921

increased by12.87%

Number of lines in readme file

371

increased by7.23%

No dependency changes