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

binding to a property getter uses dirty-checking #37

Closed
frankwallis opened this Issue Feb 18, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@frankwallis

frankwallis commented Feb 18, 2015

In the skeleton-navigation example app some text is bound to an es5 property

<div class="form-group">
    <label>Full Name</label>
    <p class="help-block">${fullName | upper}</p>
</div>
export class Welcome{
  constructor(){
    this.heading = 'Welcome to the Aurelia Navigation App!';
    this.firstName = 'John';
    this.lastName = 'Doe';
  }

  get fullName(){
    return `${this.firstName} ${this.lastName}`;
  }
  ...
}

When I run the app (in chrome) I can see that the fullName getter is called roughly every 120ms, despite nothing changing. So it appears to be 'falling back' to dirty-checking. Is this the expected behaviour, and is there another way to write this code so that the binding uses one of the more efficient binding mechanisms?

@EisenbergEffect

This comment has been minimized.

Show comment
Hide comment
@EisenbergEffect

EisenbergEffect Feb 18, 2015

Member

Yes, this is expected. There is no way to observe a getter either with Object.observe or with auto-generated properties. So, it must fall back to dirty checking.

However, we have a number of improvements that are planned.

  • The binding system is pluggable and we have designed a mechanism for plugging in the notion of "dependencies". So, you could tell the binding system that fullName depends on firstName and lastName and then it won't use dirty checking, it will just update it whenever one of the dependencies changes.
  • Right now we poll all dirty checked properties every 120ms. This is so that we don't have to force a people to call something like digest. There are a few ways we think we can improve upon this. For example, since the bulk of the system is observable (in theory) we could just run the dirty checks after any normal observable changes. This only works if we're observing the dependencies though. But, it might be that we could combine this with some other technique and get rid of the polling altogether.
  • We could also monkey-patch the entire DOM and run dirty checking after every event or async operation. This is pretty hacky though and involves mangled a lot of parts of the DOM, so I don't want to do this if we can avoid it.

We plan to start with the first two improvements and then see how that works out practically before investing any time in the third option. We are holding off on some of this until after we make a few fundamental changes in our binding system.

Member

EisenbergEffect commented Feb 18, 2015

Yes, this is expected. There is no way to observe a getter either with Object.observe or with auto-generated properties. So, it must fall back to dirty checking.

However, we have a number of improvements that are planned.

  • The binding system is pluggable and we have designed a mechanism for plugging in the notion of "dependencies". So, you could tell the binding system that fullName depends on firstName and lastName and then it won't use dirty checking, it will just update it whenever one of the dependencies changes.
  • Right now we poll all dirty checked properties every 120ms. This is so that we don't have to force a people to call something like digest. There are a few ways we think we can improve upon this. For example, since the bulk of the system is observable (in theory) we could just run the dirty checks after any normal observable changes. This only works if we're observing the dependencies though. But, it might be that we could combine this with some other technique and get rid of the polling altogether.
  • We could also monkey-patch the entire DOM and run dirty checking after every event or async operation. This is pretty hacky though and involves mangled a lot of parts of the DOM, so I don't want to do this if we can avoid it.

We plan to start with the first two improvements and then see how that works out practically before investing any time in the third option. We are holding off on some of this until after we make a few fundamental changes in our binding system.

@jdanyow

This comment has been minimized.

Show comment
Hide comment
@jdanyow

jdanyow Feb 18, 2015

Member

@frankwallis when the next release of aurelia/binding goes out (v 0.3.5) you'll be able to use this aurelia plugin to do what's described in @EisenbergEffect 's first bullet point.

This may get incorporated into the aurelia framework. Keep an eye on this issue for more details:
#15

Member

jdanyow commented Feb 18, 2015

@frankwallis when the next release of aurelia/binding goes out (v 0.3.5) you'll be able to use this aurelia plugin to do what's described in @EisenbergEffect 's first bullet point.

This may get incorporated into the aurelia framework. Keep an eye on this issue for more details:
#15

@frankwallis

This comment has been minimized.

Show comment
Hide comment
@frankwallis

frankwallis Feb 20, 2015

that looks interesting, thanks for your responses.

frankwallis commented Feb 20, 2015

that looks interesting, thanks for your responses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment