iamnoah / compute-js Goto Github PK

For computes that return an object or array, it would be useful to be able to specify a custom function that determines if the old and new values are equal, to prevent a change from firing.

Not something that I would recommend by default though, as recomputing is often cheaper than deep object comparison.

e.g., peek

http://knockoutjs.com/documentation/computedObservables.html

Instead of using the observer pattern internally, a graph of all computes should be maintained. Then a dirty sweep and a recompute sweep can be done on the graph. No external API changes.

Maybe (slightly redundant, but fast):

var INCOMING = 1; // bitmasks
var OUTGOING = 2;
$id: {
   $neighborId: INCOMING, // $id is depended on by $neighborId
   $otherNeighborId: OUTGOING, // $id depends on $otherNeighborId
},

A transaction is different from a batch in that no return values should change until the transaction finishes. (could this matter with the current batch functionality?)

In backbone-compute, Collections are not observable.

Need to observe add, sort, and remove whenever get, at, toJSON, where, findWhere or any underscore method is called. findWhere and where access models with .get so we don't need to worry about change (for the models).

R changes, F and C are dirty. Recompute F, F changes, so A recomputes. A calls B, which also needs to recompute. B calls C. C is dirty, so it recomputes its value and notifies D (then B). D recomputes and calls B. B is currently recomputing. Disaster.

The problem is the notifications in the middle. Can work around easily enough by batching around R:

compute.startBatch();
R.set(newValue);
compute.endBatch();

Need to fix this in #6

CanJS and Knockout both have computes with "compute nature" so it should be possible to generically connect them.

: and - are invalid in node names.

Depends on Refactoring (#6)

startViz/stopViz - captures what was accessed and set/rebound in between (all accessed computes are bound for the duration)

non-strict digraph.

access is shown as a normal graph, black edges.

If a value was set, the node is filled with a color.
An edge of the same color is added between the changed node and any dependencies that changed their value (and so on for their dependencies.) The changed nodes get the fill color.
Any net new dependencies are added in the same color with a dashed edge.
Any removed dependencies add an edge in the same color with a dotted edge and inverse arrow.

Each set is a new color. Nodes that end up with more than one color will get wedged. Multiple edges will be drawn for each color.