Order observation updates by their depth automatically about can-observation HOT 5 CLOSED

The thing that's fuzzy to me is if we should tear down the observations if something else is using it. Or if it would be possible for something else to be using that observation.

from can-observation.

The thing that's fuzzy to me is if we should tear down the observations if something else is using it. Or if it would be possible for something else to be using that observation.

I think it's extremely unlikely that something else is using the other observations but SHOULD NOT be torndown when the outer observation is re-calculated.

from can-observation.

The way this is implemented makes an assumption that any observations created within another observation will always be recreated whenever the parent observation is updated.

This is not always the case, for example when the child observation is cached. This is the case with can-stache, which caches observations it creates for perf reasons. See here

from can-observation.

I'm trying a slightly different approach than what is in #131. Instead of destroying all children whenever an observation is updated, will instead provide an API: trapBindings that traps calls to can.onValue. Pseudocode or how that will be used:

function fn() {
    // priority 2
    var foo = new Observation(function foo(){
        var val = bar.get();
        fooUpdates++;
        return val;
    }, {isObservable: false});

    var stopTrap = foo.trapBindings()
    Bindings.start()
    view.live(foo);
    ObservationRecorder.addBindings( stopTrap() )

    
    return foo.get();
}

from can-observation.

We are going to defer doing this change (and removing can-view-nodelist) for now. I wrote up this gist which describes where I got with the task and what the next steps would be.

from can-observation.