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

context is never received, depending on element definition order #27

Open
trusktr opened this issue Aug 3, 2024 · 0 comments
Open

context is never received, depending on element definition order #27

trusktr opened this issue Aug 3, 2024 · 0 comments

Comments

@trusktr
Copy link

trusktr commented Aug 3, 2024

For example, in an app I'm trying to use this in, neither of these logs work:

class MyEl extends ConsumerMixin(Element) {
  contexts = {
    'foo-context': (foo) => console.log('foo: ', foo) // this never fires
  }

  connectedCallback() {
    super.connectedCallback()

    console.log('foo: ', this.getContext('foo-context')) // logs 'undefined' instead of the expected value
  }
}

but this works:

class MyEl extends ConsumerMixin(Element) {
  connectedCallback() {
    super.connectedCallback()

    setTimeout(() => {
      // this works because by this time the higher-up provider is ready to provide (its connectedCallback has already ran)
      console.log('foo: ', this.getContext('foo-context')) // logs the expected value
    }, 1000)
  }
}

What we need to do is improve the pattern so that it can work regardless of upgrade orde, which I know, is very tricky!

Without a solution, the class-declarative API (contexts = {}) is not usable, and we have to resort to always calling getContext() after a delay to ensure that it always works no matter when or how end users of our elements might load those elements.

It is worth noting too, that regardless of upgrade order, the browser also calls connectedCallback in differing order (children first then parent, or parent first then children) depending on scenario, which just makes things tricky. There's just no actual guaranteed order that callbacks will fire, even if all elements are defined ahead of time.

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

No branches or pull requests

1 participant