v8.19.0
Better types for template elements
TypeScript component authors can now specify a new property, __lwc_public_property_types__
, to indicate to TypeScript which properties are available on the element created by a component. This prevents erroneous property definitions, which are otherwise unavoidable due to the way that TypeScript implements decorators.
Example
// <c-inferred-props>
class InferredProps extends LightningElement {
@api exposed = 'hello'
internal = 'secret'
}
// <c-explicit-props>
class ExplicitProps extends InferredProps {
__lwc_public_property_types__?: {
exposed: string
}
}
class Container extends LightningElement {
checkInferred() {
const inferred = this.querySelector<LightningHTMLElement<InferredProps>>('c-inferred-props')!
inferred.exposed // ✅ Valid, no type error
inferred.internal // ❌ Invalid, but no type error!
}
checkExplicit() {
const explicit = this.querySelector<LightningHTMLElement<ExplicitProps>>('c-explicit-props')!
explicit.exposed // ✅ Valid, no type error
explicit.internal // ✅ Invalid, and a type error occurs!
}
}
In this example, the element interface for c-inferred-props
is defined by LightningHTMLElement<InferredProps>
. That interface has an erroneous property definition, internal
. The internal
property is part of the component interface, but is not decorated with @api
, so it should not be part of the element interface.
The element interface for c-explicit-props
is defined by LightningHTMLElement<ExplicitProps>
. Because ExplicitProps
defines __lwc_public_property_types__
, the element interface does not include the internal
property, which is the correct behavior.
What else changed?
- feat: make it pop! (over) @W-18425406 by @wjhsf in #5357
- chore: add summer25 def to nucleus.yaml by @jhefferman-sfdc in #5365
- feat(types): add hidden helper to make inferring element types better @W-18442478 by @wjhsf in #5362
- chore: bump version to 8.19.0 by @wjhsf in #5370
- chore: release 8.19.0 by @wjhsf in #5371
Full Changelog: v8.18.2...v8.19.0