Releases: datavis-tech/reactive-model
Improved Error Messages
Nested Digests!
- Nested digests are now possible thanks to a change in reactive-function datavis-tech/reactive-function#18
- Remove property listeners on destroy. #36 This was a bug that would have caused a memory leak in some cases.
- Attach digest to instances #37 This is a simple change that makes the API a bit nicer.
Serialization & Link
- Add ability to serialize data flow graph #28 This lets you output the data flow graphs for visualization with graph-diagrams.
- Implement link function #5 An open issue for almost a year, finally closed! This adds the ability to set up data flow between different models.
- Stop storing defaults #29 A slight refactoring where the responsibility of storing defaults was pushed down to reactive-property.
API Overhaul
parameter support in model.call()
model.call()
now support parameters, like call() in d3-selection.
That way, you could have something like this:
my.call(Axis, "x", "ordinal");
For more details see #17
model.call()
As a convenient way to invoke mixins, the function model.call(fn)
has been added (see #17 ). Similarly to call() in d3-selection, the given function will be invoked, passing the model as an argument. This makes it convenient to invoke mixins and use method chaining, like this:
my
.call(ReactiveSVG)
.call(ReactiveMargin);
As an example of this, see Margin Convention II with ReactiveModel.
requestAnimationFrame
This release changes the auto-digest feature to digest on the next animation frame (using requestAnimationFrame) rather than the next tick (using setTimeout). The purpose of this change is to make it so reactive functions that do DOM manipulation only execute as frequently as necessary to update the display. Doing DOM updates more frequently than every animation does not make sense. For a more detailed discussion see #9 (comment)
Major Facelift
This release introduces new syntax for defining reactive properties. It also adds a nice way to define reactive functions with side effects but no output properties (e.g. DOM manipulation).
Here are some examples of the new syntax from the tests. For comparison with the old syntax see #14.
my("fullName", function (firstName, lastName){
return firstName + " " + lastName;
}, "firstName, lastName");
The invocation now returns the model, so is chainable.
var my = ReactiveModel()
.addPublicProperty("a", 5)
("b", function (a){
return a + 1;
}, "a");
var my = ReactiveModel()
.addPublicProperty("a", 0)
("b", increment, "a")
("c", increment, "b");
It almost starts to feel like Lisp.
my
("b", increment, "a")
("d", increment, "c")
("e", add, "b, d");
New feature - reactive functions with no output properties (e.g. DOM manipulation).
my(function (a){
sideEffect = a + 1;
}, "a");
If you appreciate my Open Source work, please consider supporting it on Patreon.
Oops
Chain React and AddProperties
Now the call to model()
for setting up reactive functions returns the model, so you can chain calls to it.
Here's a new test that shows this feature:
it("Should chain react.", function (){
var model = ReactiveModel()
.addPublicProperty("a", 5)
({
b: [function (a){
return a + 1;
}, "a"]
});
ReactiveModel.digest();
assert.equal(model.b(), 6);
});
Also, there is an alternative way to add properties using object literals:
var model = ReactiveModel()
.addPublicProperties({
x: 5,
y: 10
});
var model = ReactiveModel()
.addProperties({
x: 5,
y: 10
});