Fix race condition in element.component.js

[HaraldR42]

I found attaching the binding of an element to the ftuiApp to fail in some conditions.
Reason: ftuiApp not yet created. The error is correctly avoided by the if clause, nevertheless the expected binding will never be done.
My suggestion is to make sure that ftuiApp has been created/imported before creating any instance of an element.
The pull request should do this.

(Thanks for great work on ftui-3 !!)

[knowthelist]

My intention was to avoid the attachment of the FTUI binding by default. I could imagine, that other bindings could also be used at some point. Normally Webcomponents should be usable without any additional framework at all. I want to pursue this goal for as long as possible.

[HaraldR42]

Good reason, indeed.
Nevertheless, the problem with the race condition persists imho.

Just to illustrate the situation I've seen: On a page with quite many widgets on it (in several views), I faced the situation that a few components didn't have the binding, the rest did. Can't tell on which browser (I'm testing with Chrome, Safari and Firefox, all on MBP 14" MacOS 12.1). Happened in less than 5% of the page loads, but definitely was there.

So the question is, how to ensure that an intended binding is available when an element is created.

I'll think about it and try to come up with a different solution.
Please keep the thread open either until I surrender or we can align on a solution.

[HaraldR42]

The solution I just submitted does the following:

• Avoids a hard dependency on FtuiApp in the code
• Synchronizes on window.ftuiApp being defined to execute the binding, thus avoiding the race condition.

To be really independent from the existence of a binding, we maybe need a way to indicate if there is a binding to be expected.

[HaraldR42]

Latest submission makes solution more robust.
In addition, what about the following:

• Introduce "window.ftuiBindingProvider" to decouple having a (different) binding from the app.
• Synchronization behavior:
  • Wait for window.ftuiBindingProvider to be set.
  • If it's an object, call attachBinding().
  • If it's not an object (eg, ===null), it's intended not to have a binding.
• For now set window.ftuiBindingProvider to the instance of FtuiApp

Please tell me if you like the idea, then I would make a proposal code wise.

By the way, there are other dependencies on FtuiApp in some components. As far as I can see, most of them use it for getting configuration values.
Therefore maybe even a split into ftuiApp / ftuiConfiguration / ftuiBindingProvider would be desirable in the sense of decoupling things and reducing dependencies for future use cases. I could volunteer here too.

Just my 2 cents, thanks.