LightDOM compatibility with imperative component instanciation

[tblaisot]

Hello.

I make this post hoping it will help me to define if a bug should be submitted or not.

I encounter a problem with lion inputs when using them in angular which, after much debugging, i can't resolve on my part.
I finally understood that there is a problem/incompatibility with the lightdom approch and imperative instanciation of components. This problem may not be limited to angular, i even think that it work specifically in lit-element because of the way lit element render (single pass render of the dom and filling the gaps after).

The problem (using the officials exemples):

This code

<lion-input-email>
       <div slot="help-text">
            Help text using <a href="https://example.com/" target="_blank">html</a>
       </div>
</lion-input-email>

Will produce something like at runtime this in lit-element (i ommited a lot of attributes for lisibility)

<lion-input-email>
    <label slot="label">Email</label>
    <div slot="help-text">Help text using <a href="https://example.com/" target="_blank">html</a></div>
    <lion-validation-feedback></lion-validation-feedback>
    <input slot="input"/>
</lion-input-email>

But in angular it render like this (notice the 2 help-text slotted element):

<lion-input-email>
    <label slot="label">Email</label>
    <div slot="help-text"></div>
    <div slot="help-text">Help text using <a href="https://example.com/" target="_blank">html</a></div>
    <lion-validation-feedback></lion-validation-feedback>
    <input slot="input"/>
</lion-input-email>

This is because the above html is compiled in angular to something like this:

const n1 = document.createElement('lion-input-email')
n1.setAttributes(...)
parent.appendChild(n1) // this is THE line
const n2 = document.createElement('div')
n2.setAttributes("slot", "help-text")
n1.appendChild(n2)

During execution of this code, then executing 'THE line', connectedCallback() lifecycle method is called.

In this method, SlotMixin will check if an element is present in the slot and if not will append one creating the lightdom.
Because the child is not yet created an element will be slotted.
More over other mixins/components will check their dom during connectedCallback() to get reference to slotted elements (like lion-validation-feedback)

This is a major problem for angular but it may be for React too and for any framework which doesn't render all the node in single passe.
I think doing those dom queries asynchronously in connectedCallback should solve the problem but it mean a lot of changes in the code.
But I not even sure it will solve the problem because I can't make sure angular/react will not split the render in multiple passes but I can have hope :)
It may exist a better solution because i am not understanding all the architecture of lion elements.

[tlouisse]

Hi,

Thanks for the clear explanation. We should definitely support Angular and the likes 👍

I think your proposed example (waiting for firstUpdated (1 microtask after connectedCallback)) would indeed solve this problem, but since parents expect slottables to be present in connectedCallback this will be breaking for parents relying on this.

We could do this:

1. keep current logic in connectedCallback (add display:none to prevent FOUC)
2. check in firstUpdated whether something was slotted in the meantime. If so, delete slots created in step 1

Please feel free to make an issue (bug report) referring to this discussion. We could pick this up next week.

In the meantime you could work around it via props(but text only) if this problem blocks you atm, via <lion-input [helpText]="my.helpText"> 🙂

[tlouisse]

Hey @tblaisot ,

You're right about those concerns and I indeed foresaw those when I proposed to do it like this :)
In the end, initalizing SlotMixin in firstUpdated would be the right way (we can do this in v1), but it would be breaking to do it now.

Imagine extension layers (not using Angular or comparable framework, so relying on the fact content is already projected on connected) that do smth like:

Current situation

MyCurentInput extends LionInput {
   connectedCallback() {
     super.connectedCallback();
     // do smth with this._inputNode
   }
}

Desired situation

MyDesiredInput extends LionInput {
   firstUpdated(changedProps) {
     super.firstUpdated(changedProps);
     // do smth with this._inputNode
   }
}

If we initialize SlotMixin in firstUpdated, MyCurentInput would break in all extension layers, because _inputNode would not yet be available in connectedCallback
The desired solution can thus only be scheduled for V1

If we want to add support for Angular right now, we could do the workaround: reinitialize on firstUpdated if needed. That does indeed mean reattaching ids etc, but that would all be logic that we are in control of ourselves and thus can fix.
For an extending consumer nothing would change.

Let me know if you would be interested in contributing btw :)

[tblaisot]

I will be happy to contribute :)
I am currently checking all the components that will need changes to work with angular so i can provide a bug report with more exaustive informations.
Once done I will try to find a elegant solution to make changes without breaking actual extension code.
My best bet at it for now is to use my extension layer to integrate support for angular.

I any case Thanks for your help in this quest :)

[tlouisse]

Nice 💪 Looking forward to your report.

I think it would be really nice if Angular was compatible with Lion out of the box btw

[tblaisot]

For the most part the compatibility is already here.
Only parts i have kind of a problems with are:

• slots (but solution is achevable)
• forms
• translations
  For the two last it is only because angular expect is own system to be used.
  You will always need an very small angular lib to do the mapping between lion and angular forms but it could be done in a reusable way and shared as a companion lib

[tlouisse]

Companion lib and/or a showcase with framework integrations sounds like a good future plan.
Let us know if something could be improved wrt localization. form-core is designed to be used without our localize system at least (translations can be provided with any localisation system), the only thing that should be fixed is that is that it still indirectly loads IntlMessageFormat (which is a large dep, especially if you don't use it).
Also: @jorenbroekema is looking into using latest lit localize system, and once in place we will loose IntlMessageFormat dep anyways.