Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

WatchGroups: allow to attach/detach/move them #32

Open
tbosch opened this issue May 2, 2014 · 9 comments
Open

WatchGroups: allow to attach/detach/move them #32

tbosch opened this issue May 2, 2014 · 9 comments
Assignees

Comments

@tbosch
Copy link
Contributor

tbosch commented May 2, 2014

In the router we will have the use case to hide views from the user, and in that case, they should not be digested. However, when the view is shown again, it should be digested again.

Something like WatchGroup.suspend / WatchGroup.resume.

@tbosch
Copy link
Contributor Author

tbosch commented May 21, 2014

Actually, we need the following for templating:

RootWatchGroup:

  • newGroup(context):WatchGroup - will just create but not attach the group

WatchGroup:

  • addGroup(group:WatchGroup) - add a group to a parent group so that it gets digested
  • remove() - remove the group from its parent. Should allow the group to be added somewhere else afterwards.

@tbosch
Copy link
Contributor Author

tbosch commented May 21, 2014

@EisenbergEffect How far are you with your refactorings of the WatchGroups, caused by adding the observation strategy? For templating I really need this feature. Could you collaborate with @caitp to implement this?

@tbosch tbosch changed the title Add suspend/resume functionality for WatchGroups WatchGroups: allow to attach/detach/move them May 21, 2014
@EisenbergEffect
Copy link
Contributor

I've made good progress on the re-factoring. I think I can probably get
this done by tomorrow if that works for you.

On Wed, May 21, 2014 at 12:25 PM, Tobias Bosch [email protected]:

@EisenbergEffect https://github.com/EisenbergEffect How far are you
with your refactorings of the WatchGroups, caused by adding the observation
strategy? For templating I really need this feature. Could you collaborate
with @caitp https://github.com/caitp to implement this?


Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-43780371
.

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

@EisenbergEffect
Copy link
Contributor

We might need to also add something like "destroy" which removes a group
and also releases all internals resources.

On Wed, May 21, 2014 at 12:26 PM, Rob Eisenberg <[email protected]

wrote:

I've made good progress on the re-factoring. I think I can probably get
this done by tomorrow if that works for you.

On Wed, May 21, 2014 at 12:25 PM, Tobias Bosch [email protected]:

@EisenbergEffect https://github.com/EisenbergEffect How far are you
with your refactorings of the WatchGroups, caused by adding the observation
strategy? For templating I really need this feature. Could you collaborate
with @caitp https://github.com/caitp to implement this?


Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-43780371
.

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

@tbosch
Copy link
Contributor Author

tbosch commented May 21, 2014

Ok, great. If you have questions how to work with those linked lists,
@caitp knows :-)

On Wed, May 21, 2014 at 9:26 AM, Rob Eisenberg [email protected]:

I've made good progress on the re-factoring. I think I can probably get
this done by tomorrow if that works for you.

On Wed, May 21, 2014 at 12:25 PM, Tobias Bosch [email protected]:

@EisenbergEffect https://github.com/EisenbergEffect How far are you
with your refactorings of the WatchGroups, caused by adding the
observation
strategy? For templating I really need this feature. Could you
collaborate
with @caitp https://github.com/caitp to implement this?


Reply to this email directly or view it on GitHub<
https://github.com/angular/watchtower.js/issues/32#issuecomment-43780371>
.

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com


Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-43780583
.

@EisenbergEffect
Copy link
Contributor

@tbosch I need some more info on this. What should happen if newGroup() is called without a context? Currently, it gets the context from it's parent, but since we are creating them detached, that is no longer appropriate. What about the getter cache? What about the expression cache? All these things come from the parent, affect the internal behavior and you can't actually use the group without them. Need some more guidance before being able to proceed.

@tbosch
Copy link
Contributor Author

tbosch commented May 23, 2014

We had a hangout to clarify the issues...

EisenbergEffect added a commit that referenced this issue May 29, 2014
Previously, creating a new watch group simultaneously attached it to the parent from which it was created. Now, we have split this behavior into two steps so that it is possible to create a watch group, set up watches and then choose which parent to attach it to at a later point in time. You can also remove a watch group and attach it to a different parent. These features allow a more elegant mechanism for turning watches on/off based on whether or not the associated view is attached to the DOM. A primary use case for this is to tie into the attachedCallback/detachedCallback of the custom element lifecycle in order to better manage databinding present in element templates.

Closes issue #32
caitp pushed a commit to caitp/watchtower.js that referenced this issue May 29, 2014
Previously, creating a new watch group simultaneously attached it to the parent from which it was created. Now, we have split this behavior into two steps so that it is possible to create a watch group, set up watches and then choose which parent to attach it to at a later point in time. You can also remove a watch group and attach it to a different parent. These features allow a more elegant mechanism for turning watches on/off based on whether or not the associated view is attached to the DOM. A primary use case for this is to tie into the attachedCallback/detachedCallback of the custom element lifecycle in order to better manage databinding present in element templates.

Closes issue angular#32
caitp pushed a commit to caitp/watchtower.js that referenced this issue May 29, 2014
Previously, creating a new watch group simultaneously attached it to the parent from which it was created. Now, we have split this behavior into two steps so that it is possible to create a watch group, set up watches and then choose which parent to attach it to at a later point in time. You can also remove a watch group and attach it to a different parent. These features allow a more elegant mechanism for turning watches on/off based on whether or not the associated view is attached to the DOM. A primary use case for this is to tie into the attachedCallback/detachedCallback of the custom element lifecycle in order to better manage databinding present in element templates.

Closes issue angular#32
caitp pushed a commit to caitp/watchtower.js that referenced this issue May 29, 2014
Previously, creating a new watch group simultaneously attached it to the parent from which it was created. Now, we have split this behavior into two steps so that it is possible to create a watch group, set up watches and then choose which parent to attach it to at a later point in time. You can also remove a watch group and attach it to a different parent. These features allow a more elegant mechanism for turning watches on/off based on whether or not the associated view is attached to the DOM. A primary use case for this is to tie into the attachedCallback/detachedCallback of the custom element lifecycle in order to better manage databinding present in element templates.

Closes issue angular#32
caitp pushed a commit to caitp/watchtower.js that referenced this issue May 29, 2014
Previously, creating a new watch group simultaneously attached it to the parent from which it was created. Now, we have split this behavior into two steps so that it is possible to create a watch group, set up watches and then choose which parent to attach it to at a later point in time. You can also remove a watch group and attach it to a different parent. These features allow a more elegant mechanism for turning watches on/off based on whether or not the associated view is attached to the DOM. A primary use case for this is to tie into the attachedCallback/detachedCallback of the custom element lifecycle in order to better manage databinding present in element templates.

Closes issue angular#32
caitp pushed a commit to caitp/watchtower.js that referenced this issue May 29, 2014
Previously, creating a new watch group simultaneously attached it to the parent from which it was created. Now, we have split this behavior into two steps so that it is possible to create a watch group, set up watches and then choose which parent to attach it to at a later point in time. You can also remove a watch group and attach it to a different parent. These features allow a more elegant mechanism for turning watches on/off based on whether or not the associated view is attached to the DOM. A primary use case for this is to tie into the attachedCallback/detachedCallback of the custom element lifecycle in order to better manage databinding present in element templates.

Closes issue angular#32
EisenbergEffect added a commit that referenced this issue May 29, 2014
Previously, creating a new watch group simultaneously attached it to the parent from which it was created. Now, we have split this behavior into two steps so that it is possible to create a watch group, set up watches and then choose which parent to attach it to at a later point in time. You can also remove a watch group and attach it to a different parent. These features allow a more elegant mechanism for turning watches on/off based on whether or not the associated view is attached to the DOM. A primary use case for this is to tie into the attachedCallback/detachedCallback of the custom element lifecycle in order to better manage databinding present in element templates.

Closes issue #32
@tbosch
Copy link
Contributor Author

tbosch commented Jun 5, 2014

Hi,
there seems to be a bug when watching PureFunctions. The following test fails when rootWatchGrp.addGroup(watchGrp); is done after creating the watch, but passes when done the other way around

    iit('should dirty check function watches after attaching a child group', function() {
      context = {'a': 1};
      var rootWatchGrp = new RootWatchGroup(new GetterCache({}), null, {});
      var watchGrp = rootWatchGrp.newGroup(context);

      var watch = watchGrp.watchExpression(new PureFunctionAST('add', function(a) {
        return a+1;
      }, [parse('a')]), logCurrentValue);
      rootWatchGrp.addGroup(watchGrp);

      rootWatchGrp.detectChanges();
      expect(logger.toArray()).toEqual([2]);
    });

@tbosch
Copy link
Contributor Author

tbosch commented Jun 5, 2014

And the newGroup(context) function should only be available in RootWatchGroup...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants