-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Order observation updates by their depth automatically #125
Comments
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. |
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 |
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: 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();
} |
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. |
tldr; Observations created inside other observations should always be entered in the queue after the outer observation. If the outer observation is updated, the child observation should be "stopped" (all handlers unbound and stops listening on its dependencies).
This might eliminate one of the core abilities of nodeLists - the need to recursively unbinding child nodelists!
Background
Take some example stache code like:
This gets compiled into the following pseudo observations:
First, an
ifBlock
with a nestedLOGIC
block. The LOGIC observation is createdso
ifBlock
is not rerun over and over ifshow
were to change from 1 to 2 to 3, etc.Second,
options.fn
(and options.inverse) are compiled to something like:Proposal
The idea is to:
In the example above, if
ifBlock
were to re-run its function, bothLOGIC
andfoo
should be torn down.By
torn down
we mean all activity should stop. Any handlers listening to those observables should be removed (watch out for handlers bound with.listenTo()
). Also those observables should not be binding on their dependencies. Currently, I believecan-event-queues/value
supports calling.off()
without arguments to tear down any handlers. This should probably be formalized, possibly as acanReflect.stop()
(which could also work for Map and List types).Finally, the child-parent relationship needs to be established. I think part of this can happen with expansion of
can-observation-recorder
. An observation record could contain a set ofcreatedDependencies
:I think child observables can register themselves with:
When
can-observation
updates its value, it can go throughcreatedDependencies
and callcanReflect.stop(observable)
on each observable.Other
+ 1
,Infinity + 1
is stillInfinity
. This might mean resuming the default priority of 0.The text was updated successfully, but these errors were encountered: