Conversation
| 1. `@lwc/engine-dom` is "pure" and polyfill-free by default, which gives off-core consumers the best possible LWC experience. | ||
| 2. It aligns neatly with the existing behavior for LWC's other polyfills. | ||
| 3. If consumers do not need the polyfill, then they do not need to load the code for the polyfill (which admittedly is small – roughly 385 bytes minified+gzipped). | ||
| 4. It does not enshrine `lwcRuntimeFlags` as a user-facing API surface, which is the current ad-hoc solution to toggling native vs synthetic lifecycle. |
|
|
||
| So rather than trying to emulate synthetic-lifecycle-within-native-lifecycle (which is [a fool's errand](https://github.com/salesforce/lwc/issues/4249)), we should force the entire tree into native lifecycle mode so that `connectedCallback` and `disconnectedCallback` at least consistently fire. | ||
|
|
||
| For component authors, this means that they will have to be careful when enabling native lifecycle mode. Similar to native shadow mode, they will have to ensure that their children are all native-lifecycle ready. But in addition, they must communicate to their consumers that any _slotted_ content provided by the consumer is also beholden to this rule. |
There was a problem hiding this comment.
This is the part that really makes me hesitate, but I don't see a way around it.
There was a problem hiding this comment.
For component authors, this means that they will have to be careful when enabling native lifecycle mode. Similar to native shadow mode, they will have to ensure that their children are all native-lifecycle ready. But in addition, they must communicate to their consumers that any slotted content provided by the consumer is also beholden to this rule.
@nolanlawson Would it make sense to allow the customer to toggle the lifecycleSupportMode for an internal component?
I'm thinking of something like base components that have high external customer usage.
Something like this:
<base-component lifecycle-support-mode='native'>
<c-customer-component></c-customer-component>
</base-component>This would allow internal components to move to native lifecycle but give customer an escape hatch in case of any incompatibilities.
The main drawback I can see is that the internal components would have to design for both synthetic and native lifecycles.
There was a problem hiding this comment.
No, I am thinking of it more like this:
- Internal components will probably have to support both modes simultaneously (due to downstream impact)
- External components will have more flexibility (due to low-to-zero downstream impact)
This is almost exactly the same situation we have with shadowSupportMode BTW.
|
|
||
| ### Testing | ||
|
|
||
| For Jest testing, we can follow the same model as the existing [`nativeShadow`](https://github.com/salesforce/lwc-test/blob/master/packages/%40lwc/jest-preset/README.md#nativeshadow) config option: |
There was a problem hiding this comment.
I'm not familiar with this feature. Does it force the component to use native shadow regardless of its shadowSupportMode?
There was a problem hiding this comment.
No, it causes @lwc/synthetic-shadow to not be loaded at all.
Our Jest plugin is kind of odd in that it assumes synthetic shadow by default, but allows you to opt-in to native shadow. That's not how @lwc/engine-dom works by default in most OSS cases.
|
|
||
| ### Polyfill behavior | ||
|
|
||
| Similar to [`@lwc/synthetic-shadow`](https://www.npmjs.com/package/@lwc/synthetic-shadow) and [`@lwc/aria-reflection`](https://www.npmjs.com/package/@lwc/aria-reflection), we will isolate the code necessary for synthetic lifecycle into a standalone package: `@lwc/synthetic-lifecycle`. The polyfill can be loaded using simply: |
There was a problem hiding this comment.
Did we consider moving synthetic lifecycle into @lwc/synthetic-shadow? Seems like a reasonable fit that wouldn't cause disruption.
There was a problem hiding this comment.
I considered conflating the two, but I thought it might be best to keep them separate so we can test them separately. Same deal with @lwc/aria-reflection (yet another polyfill, loaded by default in LEX).
There was a problem hiding this comment.
Does it make sense to test them separately? Conflating the two would preclude an app from using @lwc/synthetic-shadow with default native lifecycle, but I wonder what the demand for such a configuration is.
There was a problem hiding this comment.
I guess I'm thinking that component authors may have more trouble with one than the other. In particular, it feels intuitively like it should be "easier" to move to native lifecycle than to native shadow. That said, we ideally want to move the needle on both.
There was a problem hiding this comment.
I thought about this – I'm not sure we can conflate the two together, because that would be potentially a breaking change for existing components that have shadowSupportMode = 'native'. Their timing would certainly change in native lifecycle.
3 participants
Rendered