[context] update and connectedCallback ordering causes issues

[trusktr]

I wrote more details here:

• https://github.com/open-wc/context-protocol/issues/27

Basically there is no guarantee that connectedCallback of provider and consumer will fire in the expected order, even if elements are pre-defined before any elements are created. The protocol needs to account for this somehow, in a robust way that makes it easy to follow anbd implement for end authors, so the problem is guaranteed to not happen.

Also this is probably one of the reasons people complain about custom elements. When you run into these issues and you're on a time crunch, the next best thing is to just switch backt to React/Vue/Svelte/etc, unless you have a higher-level requirement such as supporting multiple frameworks (f.e. making a UI component library in a library author context, rather than using Custom Elements for app code in an app author context).

In general, I wish there was some sort of guarantee we could place on upgrade order and lifecycle order for Custom Elements, both of which have been the single biggest pain point in writing robust elements.

The simplest solution I can think of for contexts is to use a polling strategy to wait for a context to become available, which as we all know is an undesirable solution:

class MyEl extends HTMLElement {
  // ...

  someContext

  connectedCallback() {
    const interval = setInterval(() => {
      this.someContext = getContext(this, 'some-context')

      if (this.someContext) clearInterval(interval)
    }, 100)
  }
}

We want the context to be available as soon as possible. But then imagine hundreds of elements running a tight interval loop dispatching bubbling composed events while an application is starting up.

[Westbrook]

This issue references work that became a context-provider event from the Lit team that looks to support late registered contexts that may be of use in this situation. Their usage can be found here.

[trusktr]

Ah, I see. So the concept is basically to add a listener on a node that is known to certainly exist no matter the sub trees, for example document.

Perhaps we should standardize something like context-provider in the community protocol.

[Westbrook]

Agreed. Maybe we can get @augustjk to share back some of the findings on the Lit side as per #50. If not, it would be great to see an PR with this addition were you to have a little open time, Joe... 😉