Skip to content

Releases: salesforce/lwc

v6.1.1

06 Feb 21:26
c722946
Compare
Choose a tag to compare

What's Changed

Full Changelog: v6.1.0...v6.1.1

v6.1.0

02 Feb 03:27
65d6fb1
Compare
Choose a tag to compare

What's Changed

  • fix: use more helpful error message for invalid render() return value @W-14785069 by @wjhsf in #3943
  • chore: improve license header checks @W-14846456 by @wjhsf in #3951
  • test(errors): validate error object shapes and unique codes @W-14841223 by @wjhsf in #3949
  • feat: allow computed properties in @wire if they are constants or primitives @W-14785085 by @wjhsf in #3955
  • refactor: remove shadowSupportMode = 'any' by @jmsjtu in #3953
  • chore: update non-breaking deps by @nolanlawson in #3966
  • chore(copyright): update rollup config to use correct copyright by @wjhsf in #3967
  • chore: fix broken test due to Firefox update by @nolanlawson in #3968
  • refactor: remove polyfill globalThis by @SaurabhMulay999 in #3960
  • chore: release v6.1.0 by @nolanlawson in #3969
  • chore: release v6.1.0 by @nolanlawson in #3970

New Contributors

  • @SaurabhMulay999 made their first contribution in #3960

Full Changelog: v6.0.0...v6.1.0

v6.0.0

17 Jan 20:08
5557079
Compare
Choose a tag to compare

Note

These release notes are for the Lightning Web Components framework in open source only. If you use Lightning Base Components, Lightning Web Security, or other Salesforce products on the Lightning platform, see the Summer '24 release notes.

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

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

Note

LWC v6 corresponds to Salesforce release Summer '24 (API version 61).

Summary of new features

Summary of breaking change

Breaking changes

Native custom element lifecycle

Note

This change currently only applies to consumers of the LWC open-source project outside of the Salesforce Lightning platform.

Previous versions of LWC used a synthetic (polyfill) system to call the connectedCallback and disconnectedCallback component lifecycle hooks. This was originally designed for legacy browsers such as Internet Explorer 11. Such browsers are no longer supported, and LWC v6 uses the native browser APIs instead.

Important

Native vs synthetic custom element lifecycle is not the same as native vs synthetic shadow DOM. They are two entirely separate concepts.

This change may affect the firing of connectedCallback and disconnectedCallback hooks in your components, since the previous implementation did not perfectly align with the browser standard. Most commonly, this will occur in unit tests, or when manually creating components using the lwc.createElement() API. The new behavior also fixes common memory leaks caused by disconnectedCallback not firing consistently.

Native custom element lifecycle also unlocks support for Form-Associated Custom Elements (FACE) and Element Internals.

Changes you may see to connectedCallback and disconnectedCallback behavior:

New behavior when disconnected from the DOM

Note

This situation will probably only occur when writing tests that do not connect elements to the DOM.

LWC components now only fire connectedCallback when they are actually connected to the DOM. If they are disconnected from the DOM (i.e. they are not inside the document), then connectedCallback will not fire.

For instance, if you are testing for an event to be fired from a connectedCallback, this would previously work:

export default class Foo extends LightningElement {
  connectedCallback() {
    this.dispatchEvent(new CustomEvent('foo', { bubbles: true, composed: true }))
  }
}
const element = createElement('x-foo', { is: Foo })
const div = document.createElement('div')
div.addEventListener('foo', () => {
  console.log('received foo event!')
})
div.appendChild(element) // triggers connectedCallback

In the above example, received foo event! would be logged to the console.

After this change, the above no longer triggers the connectedCallback, nor the event.

Instead, you must ensure the element is connected to the DOM:

document.body.appendChild(div)

Once the element is in the DOM tree, connectedCallback will fire as expected.

New error behavior

Note

This situation will probably only occur if you are writing tests to capture errors thrown in connectedCallback/disconnectedCallback. Most component authors should never have to deal with this.

Errors thrown by connectedCallbacks and disconnectedCallback are dispatched globally, rather than locally when elements are added/removed from the DOM.

For example, let's say you have a component that throws an error in connectedCallback:

export default class Foo extends LightningElement {
  connectedCallback() {
      throw new Error('foo')
  }
}

And then you expect to be able to catch the error synchronously on appendChild:

const element = lwc.createElement('x-foo', { is: Foo })
try {
  document.body.appendChild(element)
} catch (error) {
  console.log('caught error', error)
}
  • Old behavior: the error is caught.
  • New behavior: the error is uncaught.

The solution is to use a global error listener:

const listener = (error) => {
  console.log('Caught error', error)
}
try {
  window.addEventListener('error', listener)
  document.body.appendChild(element);
} finally {
  window.removeEventListener('error', listener)
}

If you're using @lwc/jest-*, then you can use the new toThrowInConnectedCallback API which will handle this logic for you.

Note

Events dispatched in connectedCallback and disconnectedCallback are unaffected by this change.

New timing behavior in native shadow DOM

The timing of connectedCallback has changed slightly to align with native browser standards, when using native shadow DOM.

For example, the timing of when connectedCallback fires in child components relative to parent components has changed. Consider this DOM tree:

<x-a>
  #shadow-root
  | <x-a-child>
</x-a>
<x-b>
  #shadow-root
  | <x-b-child>
</x-b>
<x-c>
  #shadow-root
  | <x-c-child>
</x-c>

Old behavior: the order of connectedCallbacks firing is:

  • x-a
  • x-b
  • x-c
  • x-c-child
  • x-b-child
  • x-a-child

New behavior: the order of connectedCallbacks firing is:

  • x-a
  • x-a-child
  • x-b
  • x-b-child
  • x-c
  • x-c-child

Note that, with the new behavior, connectedCallback fires in standard DOM depth-first tree-traversal order. (The old behavior was defined by the synthetic lifecycle polyfill, and did not follow the standard.)

The relative timing of renderedCallback has also changed due the new native connectedCallback timing. For example, consider this DOM tree:

<x-grandparent>
  <x-parent>
    <x-child></x-child>
  </x-parent>
</x-grandparent>

(Note that, in the above example, the <x-parent> and <x-child> are slotted, not part of the shadow roots of their containers.)

Old behavior: the order of lifecycle hooks firing is (example):

Component Lifecycle hook
grandparent connectedCallback
parent connectedCallback
child connectedCallback
child renderedCallback
parent renderedCallback
grandparent renderedCallback

New behavior: the order of lifecycle hooks firing is (example):

Component Lifecycle hook
grandparent connectedCallback
grandparent renderedCallback
parent connectedCallback
parent renderedCallback
child connectedCallback
child renderedCallback

Note that the above only applies to native shadow DOM. In synthetic shadow DOM, the ordering is the same, regardless of native vs synthetic custom element lifecycle (example). The same is true of light DOM (example).

In general, your components should not rely on the particular timing of `connectedCall...

Read more

v5.3.0

10 Jan 04:22
2b6c9f3
Compare
Choose a tag to compare

What's Changed

  • fix(template-compiler): exclude comments from static parts when lwc:preserve-comments is disabled by @jmsjtu in #3934
  • chore: release v5.3.0 by @nolanlawson in #3938
  • chore: release v5.3.0 by @jye-sf in #3941

Full Changelog: v5.2.2...v5.3.0

v5.0.7

10 Jan 02:13
23ee7fd
Compare
Choose a tag to compare

What's Changed

  • fix(engine-core): unrevert ARIA reflection fix and release 5.0.7 by @nolanlawson in #3937

Full Changelog: v5.0.6...v5.0.7

v5.0.6

10 Jan 01:50
ab701e5
Compare
Choose a tag to compare

What's Changed

  • fix(template-compiler): fix static part comments and release 5.0.6 by @nolanlawson in #3936

Full Changelog: v5.0.5...v5.0.6

v5.0.5

10 Jan 00:53
a7e0b54
Compare
Choose a tag to compare

What's Changed

Full Changelog: v5.0.4...v5.0.5

v5.0.4

09 Jan 18:52
95c04ba
Compare
Choose a tag to compare

What's Changed

Full Changelog: v5.0.3...v5.0.4

v5.2.2

03 Jan 23:48
f49ac28
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v5.2.1...v5.2.2

v5.2.1

20 Dec 18:36
3919bc5
Compare
Choose a tag to compare

What's Changed

Full Changelog: v5.2.0...v5.2.1