reactivity - npm Package Compare versions

Comparing version 1.3.0 to 1.3.1

lib/Monitor.js

@@ -45,7 +45,9 @@ // Generated by CoffeeScript 1.6.3
     Monitor.prototype.handle_cancel = function() {
-      return this.emit('cancel');
+      this.emit('cancel');
+      return this.emit('destroy');
     };
 
     Monitor.prototype.handle_change = function() {
-      return this.emit('change');
+      this.emit('change');
+      return this.emit('destroy');
     };
@@ -52,0 +54,0 @@

lib/Notifier.js

@@ -23,3 +23,3 @@ // Generated by CoffeeScript 1.6.3
       cancelled: 'handle_cancel',
-      changed: null
+      changed: 'handle_change'
     };
@@ -45,5 +45,11 @@
     Notifier.prototype.handle_cancel = function() {
-      return this.emit('cancel');
+      this.emit('cancel');
+      return this.emit('destroy');
     };
 
+    Notifier.prototype.handle_change = function() {
+      this.emit('change');
+      return this.emit('destroy');
+    };
+
     Notifier.prototype.user$change = function() {
@@ -50,0 +56,0 @@ var _this = this;

package.json

 {
   "name": "reactivity",
-  "version": "1.3.0",
+  "version": "1.3.1",
   "description": "Native Reactivity for Javascript",
@@ -5,0 +5,0 @@ "author": "Aldo Bucchi <[e-mail]>",

README.md

@@ -8,7 +8,9 @@ # Reactivity.io
 Using *Native* Reactivity gives you one very important feature for free:
-Changes are propagated transparently up the call stack. Native Reactivity is automatically transitive - any function that depends on a reactive function is reactive itself.
+Changes are propagated transparently up the call stack.
+Native Reactivity is automatically transitive - any function that depends on a reactive function is reactive itself.
 
 This means that there is no need to explicitly declare dependencies.
 
-The only "catch" is that everyone has to use the **same** implementation. This is the reason behind the reactivity.io effort. It defines an API and provides a cannonical implementation.
+The only "catch" is that everyone has to use the **same** implementation. 
+This is the reason behind the reactivity.io effort. It defines an API and provides a cannonical implementation.
 
@@ -241,5 +243,7 @@ # Installation
 
-Like all good ideas and patterns in software they have been discovered and rediscovered over and over again. The author of this library can attest that its first encounter with this pattern was as part of a strategy to invalidate caches when calling complex stored procedures probably 15 years ago. The implementation details were a bit different but the principle was the same. Naturally, this idea was ported to Javascript over a decade ago.
+Like all good ideas and patterns in software they have been discovered and rediscovered over and over again.
+Using a global object to allow producers talk to consumers up on the stack is common when invalidating
+database caches for example.
 
-Lately it has popped up in several places. The most notable of them all is probably the Meteor.js framework, where it is tightly coupled with the framework.
+Lately it has popped up in several places. The pattern is usually tightly coupled with the host program/framework.
 
@@ -246,0 +250,0 @@ ## Why doesn't the module use classic EventEmitters?

No alert changes

Improved metrics

Lines of code

431

increased by1.65%

Number of lines in readme file

259

increased by1.57%

Worsened metrics

Total package byte prevSize

20871

decreased by-0.13%

No dependency changes