rfc: mixed shadow mode

[ekashida]

No description provided.

[caridy]

LGTM, but the question around inspection time vs creation time is still a big one for me, let's resolve that before we merge this.

[nolanlawson]

A question that came up today is what to do about lwc:dom="manual" restrictions (e.g. cannot call div.appendChild() unless the div is in manual mode). It seems to me that mixed mode should continue enforcing these, even for components that are running in native mode, because we don't want component authors to deliberately break compat with synthetic shadow.

If @lwc/synthetic-shadow is never loaded though (100% native), then these restrictions don't need to be enforced IMO.

[pmdartus]

If @lwc/synthetic-shadow is never loaded though (100% native), then these restrictions don't need to be enforced IMO.

There is currently no guarantee that @lwc/synthetic-shadow will never be loaded. I think once we are further down the process of deprecating synthetic shadow DOM we should start removing those restrictions. Existing components will keep working but we won't surface the error when lwc:dom="manual" isn't set.

[caridy]

I think this RFC is very complete, solid piece. I still disagree with the approach of forcing leaf components to opt-in in order for higher level components to be able to opt-in, but I will not block this on the basis that this can be changed later on.

[nolanlawson]

@caridy

I still disagree with the approach of forcing leaf components to opt-in in order for higher level components to be able to opt-in

I think there may be some confusion; I'm pretty sure @ekashida and I agreed that they don't need to opt-in. Just that forcing children and grandchildren into native shadow may cause breakages if there are incompatibilities.

[caridy]

@nolanlawson I was referencing to what I read in the last paragraph of adoption strategy:

When setting shadowSupportMode to any, it will be the responsibility of the component author to ensure that all components in the subtree are compatible with native Shadow DOM. Due to the nature of this feature, it is expected that initial usage will start at the leaf components and work its way up the component tree. If a component in the subtree does not support native Shadow DOM, the component author should work with the other component author to make the appropriate updates.

Maybe the word "ensure" is the problem there, it is not clear that it means they must use "any", or just to "test" them to be "confident" that they indeed work. I was surprise that it wasn't mentioned anywhere in the doc, so it might very well be what you said, and that there is no problem at all.

[nolanlawson]

@caridy Yeah, you're right, it's ambiguous. Also arguably if you're going to the trouble of working with those leaf-component teams to make them work properly in native shadow, then they might as well switch from default to any. (Native-within-synthetic is allowed, so they might as well opt for the faster native mode.)

I guess the subtlety here is that "transitivity" is not going to wait around for an explicit signal from leaf nodes. I don't think this needs to be solved in this RFC, but we'll probably have to figure out how to message this properly.