reactivity - npm Package Compare versions

Comparing version 1.3.1 to 1.3.2

package.json

 {
   "name": "reactivity",
-  "version": "1.3.1",
+  "version": "1.3.2",
   "description": "Native Reactivity for Javascript",
@@ -12,3 +12,4 @@ "author": "Aldo Bucchi <[e-mail]>",
     "prepublish": "npm run build",
-    "postpublish": "npm run clean"
+    "postpublish": "npm run clean",
+    "bundle": "sh bundle.sh"
   },
@@ -18,3 +19,5 @@ "devDependencies": {
     "chai": "~1.5.0",
-    "coffee-script": "~1.6.3"
+    "coffee-script": "~1.6.3",
+    "browserify": "~2.34.0",
+    "uglify-js": "~2.4.0"
   },
@@ -21,0 +24,0 @@ "repository": {

README.md

 # Reactivity.io
-##The Native Reactivity Standard for Javascript
 
+## The Problem
+
+
+Let's say we want to have an HTML Paragraph showing the current time.
+
+```javascript
+
+$('p').text( getTime() )
+
+```
+
+This value will be set once ( when the script is run ) but won't change when the actual time changes, right?
+
+If we had a way of listening to changes on the result of the getTime() function, we could use this mechanism
+to periodically update our UI.
+
+```javascript
+
+on_change( getTime, function( t ){
+  $('p').text( t )
+})
+
+```
+
+We could easily create this on_change function by constantly polling getTime() for changes.
+
+```javascript
+... ( codigo waldo )
+```
+
+However, if we relied upon this strategy for a large application we would end up with lots of setTintervals
+everywhere.
+
+Reacitiviy.js provies a better way, where functions themselves can notify when their value changes.
+
+## Solution
+
+Reactivity has a subscribe function that works just like the `on_change` function above
+
+`reactivity.subscribe( function_to_watch, callback )`
+
+where `function_to_watch` is a regular javascript function and callback is a function of the form:
+`func(error, result)` ( this is the Node.js standard way of defining callbacks )
+
+
+```javascript
+
+reactivity.subscribe( getTime, function( err, res ){
+  $('p').text( res )
+})
+
+```
+
+This will work as long as whoever created `getTime` was kind enough to let us know "when" the value
+of the function changes.
+
+
+```javascript
+function getTime(){
+  var notifier = reactivity.notifier()  // request a notifier
+  setTimeout( notifier, 1000 ) // call it in 1000MS
+  return new Date().getTime()
+}
+```
+
+In a very basic sense, Reactivity hast two parts:
+
+* Publish ( use reactivity.notifier() )
+* Consumer ( use reactivity.subscribe() )
+
+We say that a function is reactive if it can notify us when its value has changed.
+( somebody was kind enough to create a reactivity.notifier() under the covers )
+
+
+### Transitivity
+
+Reactivity is transitive. This means that any function consuming a reactive function becomes
+reactive itself. For example:
+
+```javascript
+
+function getTimeWithMessage(){
+  return "The current time is :" + getTime()
+}
+
+
+reactivity.subscribe( getTimeWithMessage, function( err, res ){
+  $('p').text( res )
+})
+
+
+```
+
+Or even
+
+
+```javascript
+
+function getTimeWithMessage(){
+  return "The current time is :" + getTime()
+}
+
+function getTimeWithMessageUC(){
+  return getTimeWithMessage().toUpperCase()
+}
+
+reactivity.subscribe( getTimeWithMessageUC, function( err, res ){
+  $('p').text( res )
+})
+
+
+```
+
+## Overview
+
 *Native Reactivity* is a very simple "hack" that allows native functions and expressions in Javascript
@@ -49,10 +163,2 @@ to become Reactive. Which is a fancy way of saying that **they can notify consumers when their result changes**.
 
-Functions throw an *invalidation event* up the stack.
-However, because the stack is transient and won't exist in the future, functions
-that wish to notify a change need to request a callback so they can
-throw the event in the future.
-
-Requesting this callback will make sure that any consuming functions get a chance to ask for notifiers
-on the other side.
-
 ```javascript
@@ -59,0 +165,0 @@ function time(){

New alerts

Major refactor

Supply chain risk

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Found 1 instance in 1 package

Dynamic require

Supply chain risk

Dynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.

Found 1 instance in 1 package

Minified code

Quality

This package contains minified code. This may be harmless in some cases where minified code is included in packaged libraries, however packages on npm should not minify code.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

199253

increased by854.69%

Number of package files

16

increased by23.08%

Lines of code

3976

increased by822.51%

Number of lines in readme file

365

increased by40.93%

Worsened metrics

Dev dependency count

5

increased by66.67%

Number of low quality alerts

2

increased by100%

Number of low supply chain risk alerts

8

increased byInfinity%

Number of medium supply chain risk alerts

1

increased byInfinity%

No dependency changes