@lwc/synthetic-shadow

What's Changed

• engine-dom: Warn for insertBefore with 1 arg

• Add data-lwc-host-mutated during SSR

LWC v7.0.0 contains breaking changes. Please read carefully below if you are upgrading from v6.

If you are upgrading from v5, please upgrade to v6 first.

New features

• Class object binding for more ergonomic classes in templates

• this.style for a more ergonomic way to change component styles at runtime

• this.hostElement for an alternative to this.template.host that works in light DOM

Breaking changes

Class object binding

Class object binding is a new feature that makes it more ergonomic to render class attributes in your LWC components. As part of this feature, class rendering has changed for some uncommon use cases.

If you are using a dynamic class in your template:

<template>
  <div class={myClass}></div>
</template>

Then the rendering of this class may change if you were previously defining myClass as something other than a string, null, or undefined.

For example, consider if myClass is a boolean:

export default class extends LightningElement {
  myClass = false
}

Old behavior:

This renders:

<div class="false"></div>

New behavior:

<div class=""></div>

This change applies to booleans, numbers, functions, arrays, and objects. Below is a table summarizing the change:

In short:

• breaking

  Booleans, numbers, and functions are no longer directly stringified, but are stripped instead.

• breaking

  Arrays and objects are no longer stringified, but instead follow class object binding semantics.

This may break a component if it is using a CSS selector like these:

.false {}
.true {}
[class="1"] {}

Or if it is using querySelector or other traversal techniques that rely on the class name:

this.template.querySelector('.false')
this.template.querySelector('.true')
this.template.querySelector('[class="1"]')

In rare cases, this can also cause breakages across component boundaries. For example, if you have a global stylesheet relying on light DOM or synthetic shadow DOM, and thus the ability to pierce inside of components you don't own, then the above CSS selectors would break in that case as well.

To resolve any breakages:

• breaking

  Avoid anti-patterns for styling components.

• breaking

  In cases where you want to render a value as a string (e.g. class="false" or class="1"), convert it to a string using String(value).

This change may also require updating snapshots, e.g. in Jest tests.

New this.style property

Components can now access their CSSStyleDeclaration using this.style:

renderedCallback() {
  this.style.color = 'red'
}

This is a breaking change if the component uses this.style as an expando:

renderedCallback() {
  if (!this.style) {
    this.style = "foo"
  }
}

In the above case, the component author may assume that this.style is initially undefined, and then set it to a new value ("foo"). After this change, the above code will not work as expected, because this.style is initially truthy rather than undefined.

To resolve this, set a class property on the component, initialized to undefined, rather than using an expando:

+ style = undefined
  
  renderedCallback() {
    if (!this.style) {
      this.style = "foo"
    }
  }

You may also rename your this.style expando to something else (e.g. this.customStyle).

New this.hostElement property

Components can now access this.hostElement as a convenient alternative to this.template.host:

renderedCallback() {
  console.log(this.template.host) // <x-component>
  console.log(this.hostElement)   // <x-component>
}

Additionally, this works in light DOM components to access the "host" element (similar to the :host CSS pseudo-class in light DOM scoped styles). This provides an ergonomic way to access the root HTMLElement object in either light DOM or shadow DOM components.

Similar to the new this.style property, this is a breaking change if you are using this.hostElement already as an expando. Refer to the this.style release notes for a resolution.

Improved TypeScript types

The TypeScript definitions for the lwc package are greatly improved, to more closely match the ground truth of the actual APIs for LightningElement, createElement, etc. at runtime. You may need to adjust your TypeScript code or version to adapt to the new typings.

Summary

• breaking

  The minimum supported version of TypeScript is v5.4.5.

• breaking

  The only supported compiler target is "ESNext".

• breaking

  ContextValue has been renamed to WireContextValue.

• breaking

  ContextConsumer has been renamed to WireContextConsumer.

• breaking

  Contextualizer has been renamed to WireContextProvider.

• breaking

  StylesheetFactory has been renamed to Stylesheet.

• breaking

  StylesheetFactories has been renamed to Stylesheets.

• breaking

  StringKeyedRecord has been removed. Instead, use the type Record<string, any>.

• breaking

  ShadowSupportMode has been removed. Instead, use the string values "any", "reset", or "native".

• breaking

  WireAdapter is now a generic type with a default type parameter.

• breaking

  WireAdapterConstructor is now a generic type with a default type parameter.

• breaking

  All decorators can now be used with the new decorator implementation introduced in TypeScript v5 as well as the old, experimental implementation.

• breaking

  this.template is now possibly null, reflecting the state for components using light DOM.

• breaking

  this.template.host in a LightningElement is now typed as HTMLElement, rather than the broader Element.

• breaking

  The return type of createElement has been updated to reflect the fact that the element created contains the @api-decorated props from the component definition.

  • A new helper type, LightningHTMLElement, has been introduced to provide an easy way of accessing the return type.

    const cmp: LightningHTMLElement<MyComponent> = createElement('my-component', { is: MyComponent });

  • WARNING: Due to limitations of TypeScript, this new type incorrectly contains all props defined on the component, not just decorated props. Only decorated props are accessible at runtime.

• breaking

  Importing from "lwc" now provides module definitions for HTML/CSS imports. The module definitions are also available by directly importing a new package, @lwc/types.

Common breakages and fixes

@lwc/template-compiler API changes

Due to a refactoring of the @lwc/compiler and @lwc/template-compiler packages, the @lwc/template-compiler compile function now requires the component's file name (i.e. the namespace and name options) when compiling the template.

To resolve the breaking change, add the new options. For example:

import { compile } from '@lwc/template-compiler'

compile({
  ...previousOptions,
  // Assuming the component is `<x-foo>`:
  namespace: 'x',
  name: 'foo',
})

What's Changed

• lightning-element: Expose hostElement property

• Put this.hostElement behind API version 62

• Allow access to host CSSStyleDeclaration via this.style

• Template class object binding

• types: Update types for v7