cyclejs/cyclejs
### [`v0.19.0`](https://togithub.com/cyclejs/cyclejs/compare/v0.18.0...v0.19.0)
[Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.18.0...v0.19.0)
### [`v0.18.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.18.0)
[Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.16.0...v0.18.0)
The only breaking change in this version is very small: DataFlowSink.inject() now returns the input it was given, instead of returning the Rx.Disposable that the definitionFn of DataFlowSink returns. This makes DataFlowSink consistent with DataFlowNode and DataFlowSource.
**BEFORE**
```javascript
sink.inject(node1).inject(node2); // THROWS ERROR because sink.inject(node1) returns Rx.Disposable
```
**AFTER**
```javascript
sink.inject(node1).inject(node2); // works fine, because sink.inject(node1) returns node1
```
* * *
**`dispose()` function on DataFlowNode and DataFlowSink.** These classes contain Rx.Disposable internally, and in the rare use case that you need to dispose them, this function allows you to do that. Normally you don't need to do this since DataFlowNodes are created once on application bootstrap and intended to live forever during the application run. Use dispose() in case you are dynamically creating and destroying DataFlowNodes.
* * *
**`get()` function added to DataFlowSource.** It was missing and should exist to stay consistent with DataFlowNode.
* * *
These are the functions that each type contains.
| contains? | DataFlowSource | DataFlowNode | DataFlowSink |
|-----------|----------------|--------------|--------------|
| get() | YES | YES | no |
| inject() | no | YES | YES |
| dispose() | no | YES | YES |
### [`v0.16.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.16.0)
[Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.15.0...v0.16.0)
`clone()` removed from all DataFlowNodes, including Model, View, Intent, and DOMUser. This is in order to [reduce API surface](http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-api-surface-area-learning-patterns-instead-of-frameworks.html), and clone() isn't essential, and is easily replaceable.
**BEFORE**
```javascript
var node = Cycle.createDataFlowNode(function (input) {
return {out$: input.delay(100)};
});
var cloned = node.clone();
```
**AFTER**
```javascript
function definitionFn(input) {
return {out$: input.delay(100)};
}
var node = Cycle.createDataFlowNode(definitionFn);
var cloned = Cycle.createDataFlowNode(definitionFn);
```
* * *
v0.16 also adds a `type` property to each DataFlowNode and other entities. For instance
```javascript
var node = Cycle.createDataFlowNode(function (input) {
return {out$: input.delay(100)};
});
console.log(node.type); // 'DataFlowNode'
```
```javascript
var view = Cycle.createView(function (input) {
return {vtree$: input.delay(100)};
});
console.log(view.type); // 'View'
```
### [`v0.15.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.15.0)
[Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.14.0...v0.15.0)
Very small breaking change to the API to use custom elements, but nevertheless a breaking change. This version fixes custom element glitches such as the ones described in [#77](https://togithub.com/cyclejs/cyclejs/issues/77). Most of your v0.14 code will work in v0.15, but we advise to use keys on custom elements as much as possible.
**BEFORE**
```javascript
h('my-customelem', {foo: 'all your base are belong to us'})
```
**AFTER**
```javascript
h('my-customelem', {key: 1, foo: 'all your base are belong to us'})
```
Notice the key for the custom element. This is a virtual-dom `key` attribute for virtual-dom Widgets.
This breaking change and advice also makes a lot of sense for rendering as a whole, this is not a leak in the abstraction. It is necessary for identifying that the element in question is still the same even though its properties might have changed. Counterexample:
Imagine you have a custom element `'gif-with-filters'` which plays an animated gif, but you can specify a color filter such as "black and white" or "sepia". If you don't use a key for this element, when the filter property changes (for instance from BW to sepia), we will have an ambiguous situation. The virtual DOM diff and patch will not know whether you want to (1) replace the current gif-with-filters BW with a **new** gif-with-filters sepia, hence **restarting** the gif animation, or (2) keep the same gif-with-filters element but just swap the filter from BW to sepia without restarting the animation. To fix this ambiguity we use keys. If you want (1), then you provide a different key when you change the filter. If you want (2), then you provide the same key but change the filter property. Both cases (1) and (2) should be equally easy to express, and should be a responsibility of the app developer.
### [`v0.14.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.14.0)
[Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.13.0...v0.14.0)
`User.event$(selector, eventName)` was not working for some custom elements. This fix supports only a selector which is a single class name, e.g., `.foo`. Using simple and single class names for elements in your Views is also a best practice for development.
### [`v0.13.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.13.0)
[Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.12.0...v0.13.0)
**When registering a custom element, the `definitionFn` used to expect two parameters: `element` and `Properties`. With this breaking change, `element` is replaced with `User`.**
The purpose is to prepare the API for the upcoming HTMLRenderer for server-side rendering, and also for reducing boilerplate, since any custom element implementation had to define a User in the same exact way: `var User = Cycle.createDOMUser(element);`.
Migration guide:
**BEFORE**
```javascript
Cycle.registerCustomElement('my-element', function (element, Properties) {
var View = Cycle.createView(function (Properties) {
return {vtree$: Properties.get('foo$').map((x) => h('h3', String(x)))};
});
var User = Cycle.createDOMUser(element); // notice this
User.inject(View);
});
```
**AFTER**
```javascript
Cycle.registerCustomElement('my-element', function (User, Properties) {
var View = Cycle.createView(function (Properties) {
return {vtree$: Properties.get('foo$').map((x) => h('h3', String(x)))};
});
User.inject(View);
});
```
Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Enabled.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, check this box
This PR has been generated by Renovate Bot. View repository job log here.
This PR contains the following updates:
0.12.0->0.19.0Release Notes
cyclejs/cyclejs
### [`v0.19.0`](https://togithub.com/cyclejs/cyclejs/compare/v0.18.0...v0.19.0) [Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.18.0...v0.19.0) ### [`v0.18.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.18.0) [Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.16.0...v0.18.0) The only breaking change in this version is very small: DataFlowSink.inject() now returns the input it was given, instead of returning the Rx.Disposable that the definitionFn of DataFlowSink returns. This makes DataFlowSink consistent with DataFlowNode and DataFlowSource. **BEFORE** ```javascript sink.inject(node1).inject(node2); // THROWS ERROR because sink.inject(node1) returns Rx.Disposable ``` **AFTER** ```javascript sink.inject(node1).inject(node2); // works fine, because sink.inject(node1) returns node1 ``` * * * **`dispose()` function on DataFlowNode and DataFlowSink.** These classes contain Rx.Disposable internally, and in the rare use case that you need to dispose them, this function allows you to do that. Normally you don't need to do this since DataFlowNodes are created once on application bootstrap and intended to live forever during the application run. Use dispose() in case you are dynamically creating and destroying DataFlowNodes. * * * **`get()` function added to DataFlowSource.** It was missing and should exist to stay consistent with DataFlowNode. * * * These are the functions that each type contains. | contains? | DataFlowSource | DataFlowNode | DataFlowSink | |-----------|----------------|--------------|--------------| | get() | YES | YES | no | | inject() | no | YES | YES | | dispose() | no | YES | YES | ### [`v0.16.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.16.0) [Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.15.0...v0.16.0) `clone()` removed from all DataFlowNodes, including Model, View, Intent, and DOMUser. This is in order to [reduce API surface](http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-api-surface-area-learning-patterns-instead-of-frameworks.html), and clone() isn't essential, and is easily replaceable. **BEFORE** ```javascript var node = Cycle.createDataFlowNode(function (input) { return {out$: input.delay(100)}; }); var cloned = node.clone(); ``` **AFTER** ```javascript function definitionFn(input) { return {out$: input.delay(100)}; } var node = Cycle.createDataFlowNode(definitionFn); var cloned = Cycle.createDataFlowNode(definitionFn); ``` * * * v0.16 also adds a `type` property to each DataFlowNode and other entities. For instance ```javascript var node = Cycle.createDataFlowNode(function (input) { return {out$: input.delay(100)}; }); console.log(node.type); // 'DataFlowNode' ``` ```javascript var view = Cycle.createView(function (input) { return {vtree$: input.delay(100)}; }); console.log(view.type); // 'View' ``` ### [`v0.15.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.15.0) [Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.14.0...v0.15.0) Very small breaking change to the API to use custom elements, but nevertheless a breaking change. This version fixes custom element glitches such as the ones described in [#77](https://togithub.com/cyclejs/cyclejs/issues/77). Most of your v0.14 code will work in v0.15, but we advise to use keys on custom elements as much as possible. **BEFORE** ```javascript h('my-customelem', {foo: 'all your base are belong to us'}) ``` **AFTER** ```javascript h('my-customelem', {key: 1, foo: 'all your base are belong to us'}) ``` Notice the key for the custom element. This is a virtual-dom `key` attribute for virtual-dom Widgets. This breaking change and advice also makes a lot of sense for rendering as a whole, this is not a leak in the abstraction. It is necessary for identifying that the element in question is still the same even though its properties might have changed. Counterexample: Imagine you have a custom element `'gif-with-filters'` which plays an animated gif, but you can specify a color filter such as "black and white" or "sepia". If you don't use a key for this element, when the filter property changes (for instance from BW to sepia), we will have an ambiguous situation. The virtual DOM diff and patch will not know whether you want to (1) replace the current gif-with-filters BW with a **new** gif-with-filters sepia, hence **restarting** the gif animation, or (2) keep the same gif-with-filters element but just swap the filter from BW to sepia without restarting the animation. To fix this ambiguity we use keys. If you want (1), then you provide a different key when you change the filter. If you want (2), then you provide the same key but change the filter property. Both cases (1) and (2) should be equally easy to express, and should be a responsibility of the app developer. ### [`v0.14.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.14.0) [Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.13.0...v0.14.0) `User.event$(selector, eventName)` was not working for some custom elements. This fix supports only a selector which is a single class name, e.g., `.foo`. Using simple and single class names for elements in your Views is also a best practice for development. ### [`v0.13.0`](https://togithub.com/cyclejs/cyclejs/releases/v0.13.0) [Compare Source](https://togithub.com/cyclejs/cyclejs/compare/v0.12.0...v0.13.0) **When registering a custom element, the `definitionFn` used to expect two parameters: `element` and `Properties`. With this breaking change, `element` is replaced with `User`.** The purpose is to prepare the API for the upcoming HTMLRenderer for server-side rendering, and also for reducing boilerplate, since any custom element implementation had to define a User in the same exact way: `var User = Cycle.createDOMUser(element);`. Migration guide: **BEFORE** ```javascript Cycle.registerCustomElement('my-element', function (element, Properties) { var View = Cycle.createView(function (Properties) { return {vtree$: Properties.get('foo$').map((x) => h('h3', String(x)))}; }); var User = Cycle.createDOMUser(element); // notice this User.inject(View); }); ``` **AFTER** ```javascript Cycle.registerCustomElement('my-element', function (User, Properties) { var View = Cycle.createView(function (Properties) { return {vtree$: Properties.get('foo$').map((x) => h('h3', String(x)))}; }); User.inject(View); }); ```Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Enabled.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "
rebase!".:no_bell: Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot. View repository job log here.