Comparing version 0.3.1 to 0.3.2
{ | ||
"name": "snabbdom", | ||
"version": "0.3.1", | ||
"version": "0.3.2", | ||
"description": "A virtual DOM library with focus on simplicity, modularity, powerful features and performance.", | ||
@@ -13,4 +13,6 @@ "main": "snabbdom.js", | ||
"benchmark": "^1.0.0", | ||
"browserify": "^13.0.0", | ||
"fake-raf": "0.0.1", | ||
"knuth-shuffle": "^1.0.1" | ||
"knuth-shuffle": "^1.0.1", | ||
"testem": "^1.0.2" | ||
}, | ||
@@ -17,0 +19,0 @@ "scripts": { |
119
README.md
@@ -17,2 +17,3 @@ # Snabbdom | ||
* [Helpers](#helpers) | ||
* [Structuring applications](#structuring-applications) | ||
@@ -30,3 +31,3 @@ ## Why | ||
is only ≈ 200 SLOC. It offers a modular architecture with rich functionality | ||
for extensions through custom modules. To keep the core simple all non-essential | ||
for extensions through custom modules. To keep the core simple, all non-essential | ||
functionality is delegated to modules. | ||
@@ -42,10 +43,10 @@ | ||
* Core features | ||
* About 200 SLOC – you could easily read through the entire core and fully. | ||
* About 200 SLOC – you could easily read through the entire core and fully | ||
understand how it works. | ||
* Extendable through modules. | ||
* A rich set of hooks available both per vnode and globally for modules. | ||
* A rich set of hooks available both per vnode and globally for modules, | ||
so they can hook into any part of the diff and patch process. | ||
* Splendid performance. Snabbdom is among the fastest virtual DOM libraries. | ||
* Splendid performance. Snabbdom is among the fastest virtual DOM libraries | ||
in the [Virtual DOM Benchmark](http://vdom-benchmark.github.io/vdom-benchmark/). | ||
* Patch function with a function signature equivelant to a reduce/scan. | ||
* Patch function with a function signature equivelant to a reduce/scan | ||
function. Allows for easier integration with a FRP library. | ||
@@ -102,3 +103,3 @@ * Features in modules | ||
The core exposes only one single function `snabbdom.init`. `init` takes a list of | ||
The core exposes only one single function `snabbdom.init`. This `init` takes a list of | ||
modules and returns a `patch` function that uses the specified set of modules. | ||
@@ -119,5 +120,5 @@ | ||
If a DOM element with a parent is passed `newVnode` will be turned into a DOM | ||
node and the passed element will be replaced by the created DOM node. If an old | ||
vnode is passed Snabbdom will effeciently modify to match the description in | ||
If a DOM element with a parent is passed, `newVnode` will be turned into a DOM | ||
node, and the passed element will be replaced by the created DOM node. If an old | ||
vnode is passed, Snabbdom will effeciently modify it to match the description in | ||
the new vnode. | ||
@@ -152,3 +153,3 @@ | ||
offers a rich selection of hooks. Hooks are used both by modules to | ||
extend Snabbdom and in normal code for executing arbitrary code at | ||
extend Snabbdom, and in normal code for executing arbitrary code at | ||
desired points in the life of a virtual node. | ||
@@ -161,2 +162,3 @@ | ||
| `pre` | the patch process begins | none | | ||
| `init` | a vnode has been added | vnode | | ||
| `create` | a DOM element has been created based on a VNode | `emptyVNode, vnode` | | ||
@@ -167,3 +169,3 @@ | `insert` | an element has been inserted into the DOM | `vnode` | | ||
| `postpatch` | an element has been patched | `oldVnode, vnode` | | ||
| `destroy` | an element is directly or indirectly begin removed | `vnode` | | ||
| `destroy` | an element is directly or indirectly being removed | `vnode` | | ||
| `remove` | an element is directly being removed from the DOM | `vnode, removeCallback` | | ||
@@ -176,3 +178,3 @@ | `post` | the patch process is done | none | | ||
The following hooks are available in the `hook` property of individual | ||
elements: `create`, `insert`, `prepatch`, `update`, `postpatch`, | ||
elements: `init`, `create`, `insert`, `prepatch`, `update`, `postpatch`, | ||
`destroy`, `remove`. | ||
@@ -194,2 +196,11 @@ | ||
#### The `init` hook | ||
This hook is invoked during the patch process when a new virtual node has been | ||
found. The hook is called before Snabbdom has processed the node in any way. | ||
I.e. before at has created a DOM node based on the vnode. | ||
If the hook handler sets the `vnode` property on the vnode, then Snabbdom will | ||
use the vnode at `vnode` instead of the actual vnode. | ||
#### The `insert` hook | ||
@@ -206,9 +217,9 @@ | ||
Allows you to hook into the removal of an element. The hook is called once a | ||
vnode is to be removed from the DOM. The handling function recieves both the | ||
vnode is to be removed from the DOM. The handling function receives both the | ||
vnode and a callback. You can control and delay the removal with the callback. | ||
It should be invoked once the hook is done doing its business and the element | ||
It should be invoked once the hook is done doing its business, and the element | ||
will only be removed once all `remove` hooks have invoked their callback. | ||
The hook is only triggered when and element is to be removed from its parent – | ||
not if it is the child of an element that is removed. For that see the destroy | ||
The hook is only triggered when an element is to be removed from its parent – | ||
not if it is the child of an element that is removed. For that, see the destroy | ||
hook. | ||
@@ -218,7 +229,5 @@ | ||
This hook is invoked whenever an element removed from the DOM or the child | ||
to an element that is being removed. | ||
This hook is invoked on a virtual node when its DOM element is removed from the DOM or if its parent is being removed from the DOM. | ||
To see the difference between this hook and the `remove` hook consider an | ||
To see the difference between this hook and the `remove` hook, consider an | ||
example. | ||
@@ -239,3 +248,3 @@ | ||
being removed and use the `destroy` hook to additionally animate the | ||
disappearance of the removed elements children. | ||
disappearance of the removed element's children. | ||
@@ -258,3 +267,3 @@ ### Creating modules | ||
With this mechanism you can easily augument the behaviour of | ||
Snabbdom. For demonstration take a look at the implementations of the | ||
Snabbdom. For demonstration, take a look at the implementations of the | ||
default modules. | ||
@@ -287,3 +296,3 @@ | ||
Same as props but set attributes instead of properties on DOM elements | ||
Same as props, but set attributes instead of properties on DOM elements. | ||
@@ -294,12 +303,12 @@ ```javascript | ||
Attributes are added and updated using `setAttribute`. In case of an attribute | ||
that has been previously added/set is no longer present in the `attrs` object, | ||
it is removed from the DOM element's attribute list using `removeAttribute`. | ||
Attributes are added and updated using `setAttribute`. In case of an attribute | ||
that has been previously added/set and is no longer present in the `attrs` object, | ||
it is removed from the DOM element's attribute list using `removeAttribute`. | ||
In the case of boolean attributes (.e.g. `disabled`, `hidden`, `selected` ...). | ||
The meaning doesn't depend on the attribute value (`true` or `false`) but depends | ||
instead on the presence/absence of the attribute itself in the DOM element. Those | ||
attributes are handled differently by the module : if a boolean attribute is set | ||
to a [falsy value](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean) (`0`, `-0`, `null`, `false`,`NaN`, `undefined`, or the empty | ||
string (`""`)) then the attribute will be removed from the attribute list of the | ||
In the case of boolean attributes (e.g. `disabled`, `hidden`, `selected` ...), | ||
the meaning doesn't depend on the attribute value (`true` or `false`) but depends | ||
instead on the presence/absence of the attribute itself in the DOM element. Those | ||
attributes are handled differently by the module: if a boolean attribute is set | ||
to a [falsy value](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean) (`0`, `-0`, `null`, `false`,`NaN`, `undefined`, or the empty | ||
string (`""`)), then the attribute will be removed from the attribute list of the | ||
DOM element. | ||
@@ -319,3 +328,3 @@ | ||
Note that the style module does not remove style attributes if they are removed | ||
as properties from the style object. To remove a style you should instead set | ||
as properties from the style object. To remove a style, you should instead set | ||
it to the empty string. | ||
@@ -331,3 +340,3 @@ | ||
You can specify properties as being delayed. Whenever these properties change | ||
You can specify properties as being delayed. Whenever these properties change, | ||
the change is not applied until after the next frame. | ||
@@ -346,4 +355,4 @@ | ||
Styles set in the `remove` property will take effect once the element is about | ||
to be moved from the DOM. The applied styles should be animated with CSS | ||
transitions. Only once all the styles is done animating will the element be | ||
to be removed from the DOM. The applied styles should be animated with CSS | ||
transitions. Only once all the styles is done animating, will the element be | ||
removed from the DOM. | ||
@@ -384,3 +393,3 @@ | ||
Very often however you're not really interested in the event object itself. | ||
Very often, however, you're not really interested in the event object itself. | ||
Often you have some data associated with the element that triggers an event | ||
@@ -391,3 +400,3 @@ and you want that data passed along instead. | ||
by 1, one to increment the counter by 2 and one to increment the counter by 3. | ||
You're don't really care exactly which button was pressed. Instead you're | ||
You don't really care exactly which button was pressed. Instead you're | ||
interested in what number was associated with the clicked button. The event listeners | ||
@@ -423,7 +432,7 @@ module allows one to express that by supplying an array at the named event property. | ||
h('div', [ | ||
h('input', {props: {type: 'radio', name: 'test', value: '0'}, | ||
h('input', {props: {type: 'radio', name: 'test', value: '0'}, | ||
on: sharedHandler}), | ||
h('input', {props: {type: 'radio', name: 'test', value: '1'}, | ||
h('input', {props: {type: 'radio', name: 'test', value: '1'}, | ||
on: sharedHandler}), | ||
h('input', {props: {type: 'radio', name: 'test', value: '2'}, | ||
h('input', {props: {type: 'radio', name: 'test', value: '2'}, | ||
on: sharedHandler}) | ||
@@ -440,7 +449,7 @@ ]); | ||
h('div', [ | ||
h('input', {props: {type: 'radio', name: 'test', value: '0'}, | ||
h('input', {props: {type: 'radio', name: 'test', value: '0'}, | ||
on: {change: sharedHandler}}), | ||
h('input', {props: {type: 'radio', name: 'test', value: '1'}, | ||
h('input', {props: {type: 'radio', name: 'test', value: '1'}, | ||
on: {change: sharedHandler}}), | ||
h('input', {props: {type: 'radio', name: 'test', value: '2'}, | ||
h('input', {props: {type: 'radio', name: 'test', value: '2'}, | ||
on: {change: sharedHandler}}) | ||
@@ -471,3 +480,3 @@ ]); | ||
The `thunk` function takes a name for identifying a thunk, a function that | ||
returns a vnode and a variable amount of state parameters. If invoked the | ||
returns a vnode and a variable amount of state parameters. If invoked, the | ||
render function will recieve the state parameters. | ||
@@ -488,3 +497,3 @@ | ||
The view depends only on `n`. This means that if `n` is unchanged then | ||
The view depends only on `n`. This means that if `n` is unchanged, then | ||
creating the virtual DOM node and patching it against the old vnode is | ||
@@ -501,3 +510,3 @@ wasteful. To avoid the overhead we can use the `thunk` helper function. | ||
a dummy vnode in the virtual tree. When Snabbdom patches this dummy vnode | ||
against a previous vnode it will compare the value of `n`. If `n` is unchanged | ||
against a previous vnode, it will compare the value of `n`. If `n` is unchanged | ||
it will simply reuse the old vnode. This avoids recreating the number view and | ||
@@ -510,1 +519,17 @@ the diff process altogether. | ||
## Structuring applications | ||
Snabbdom is a low-level virtual DOM library. It is unopinionated with | ||
regards to how you should structure your application. | ||
Here are some approaches to building applications with Snabbdom. | ||
* [functional-frontend-architecture](https://github.com/paldepind/functional-frontend-architecture) – | ||
a repository containing several example applications that | ||
demonstrates an architecture that uses Snabbdom. | ||
* [Motorcycle.js](https://github.com/motorcyclejs/core) – | ||
is a variant of the functional and reactive Javascript framework | ||
[Cycle.js](http://cycle.js.org/) that uses Snabbdom. | ||
Be sure to share it if you're building an application in another way | ||
using Snabbdom. |
@@ -214,3 +214,3 @@ // jshint newcap: false | ||
for (i = 0; i < cbs.pre.length; ++i) cbs.pre[i](); | ||
if (oldVnode instanceof Element) { | ||
if (oldVnode.nodeType === Element.ELEMENT_NODE) { | ||
if (oldVnode.parentElement !== null) { | ||
@@ -217,0 +217,0 @@ createElm(vnode, insertedVnodeQueue); |
@@ -110,2 +110,18 @@ var assert = require('assert'); | ||
}); | ||
it('can create an element created inside an iframe', function(done) { | ||
// Only run if srcdoc is supported. | ||
var frame = document.createElement('iframe'); | ||
if (typeof frame.srcdoc !== 'undefined') { | ||
frame.srcdoc = "<div>Thing 1</div>"; | ||
frame.onload = function() { | ||
patch(frame.contentDocument.body.querySelector('div'), h('div', 'Thing 2')); | ||
assert.equal(frame.contentDocument.body.querySelector('div').textContent, 'Thing 2'); | ||
frame.remove(); | ||
done(); | ||
}; | ||
document.body.appendChild(frame); | ||
} else { | ||
done(); | ||
} | ||
}); | ||
}); | ||
@@ -112,0 +128,0 @@ describe('pathing an element', function() { |
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Uses eval
Supply chain riskPackage uses dynamic code execution (e.g., eval()), which is a dangerous practice. This can prevent the code from running in certain environments and increases the risk that the code may contain exploits or malicious behavior.
Found 1 instance in 1 package
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
508
6
0
165581
5
34
3467