Skip to content
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

Support a lifecycle hook that runs prior to bindings being torn down. #328

Open
justinbmeyer opened this issue Feb 15, 2019 · 1 comment

Comments

@justinbmeyer
Copy link
Contributor

justinbmeyer commented Feb 15, 2019

In this codepen, <child-comp> is trying to change it's viewModel when it is being removed from the page.

However, the parent<my-counter> is not updated. This is because the binding is torndown prior to the event being dispatched. The bindings teardown somehow needs to be delayed. It's likely we need to run a batch around before remove.

Adding a batch around beforeremove does not seem to help. The updates likely happen too late (in DOMUI). Perhaps child->parent updates should happen in Notify?

A quick fix is to pass a compute that sets your property down to the child. The child can then set that compute:

https://codepen.io/justinbmeyer/pen/rPQBRv?editors=0011

@justinbmeyer
Copy link
Contributor Author

Here's a proposed fix for this. First we add a beforeDisconnected() hook on either the ViewModel or component directly.

Component.extend({
  ViewModel: {
    beforeDisconnected( element ){
      this.prop = Math.random(); // This?
    }
  },
  beforeDisconnected(){
    this.viewModel.prop = Math.random() // Or this?
  }
})

Then, in order to fix this, ONLY if someone has a beforeDisconnected() callback will:

  • Call beforeDisconnected as the nodeList is being torn down.
  • Move calling teardownBindings and viewModelDisconnectedCallback to be called in the mutateQueue instead of immediately.

This will allow bindings to still work. However, the timing of later callbacks will change ... they are going to be postponed. I don't know if this can cause any other problems. I don't think it will cause memory leaks.

What I don't like:

  • The timing of disconnectedCallback changes to happen in a mutate queue.

What I like about this is:

  • It fixes the problem
  • The timing of disconnectedCallback changes, but this might not be a big deal for most (any?) apps ... but it ONLY changes in components that are using beforeDisconnected

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

No branches or pull requests

2 participants