Elements schedule updates after an update completed

[Rhaoma]

Describe the bug
Several of our elements seem to schedule updates after an update completed.
It is a Lit emitted warning when using a development bundled version, but I only discovered it due to the fact I'm locally bundling Lit and not loading it from a CDN (jsDelivr).

I havent looked into the cause yet, and it might be that this is needed/intended behavior, but I think it should be noted.

Below are a list of warnings emitted by Lit upon page load of a docs page

Components known to schedule updates after a completed update:

• m3e-bottom-sheet
• m3e-drawer-container
• m3e-form-field
• m3e-list-item
• m3e-list-item-button
• m3e-list-item-option
• m3e-slider-group
• m3e-toc
• m3e-circular-progress-indicator
• m3e-linear-progress-indicator
• m3e-slide-group

The official docs page doesn't emit the warnings even though Lit is in dev mode.
It seems that when checking whether a warning should be emitted the const DEV_MODE is undefined, even though it is initially set to true;

To Reproduce / Reproduction Code
You can verify my findings by visiting the docs page in Chrome, set a breakpoint at source https://cdn.jsdelivr.net/npm/@lit/reactive-element@2.1.0/src/reactive-element.ts line 1552, and enter following conditional breakpoint code, which will log every unique element who scheduled an update right after another update:

let logUpdatingElements = (name,  isUpdatePending) => {
  if (!isUpdatePending) return false;
  const globalVar = globalThis.parent;
  (globalVar.changeInUpdate ??= []); 
  if (!globalVar.changeInUpdate.includes(name)) {
    globalVar.changeInUpdate.push(name); 
    console.log(name);
  }
  return false;
}
logUpdatingElements(this.localName, this.isUpdatePending);

Navigating around the different pages will then slowly log all the relevant elements as they are shown;

Note that dependent on the browser i get different reactive-elements versions called. Optionally set a breakpoint at every one and check console output.

Please provide a minimal HTML/JS/CSS snippet or link to a repository that demonstrates the issue:

[matraic]

Using the showcase and adding a breakpoint in reactive-element.js under reactive-element@1.6.3/development folder on line 867 shows DEV_MODE set to true and removing that breakpoint and setting one on line 870 where it issues the warning is never hit.

However, this issue can be caused by multiple Lit runtimes being bundled. It was observed specifically when testing @m3e/react under React + Next.js. Fast Refresh (HMR) can re‑bundle Lit during development, resulting in multiple Lit instances on the page.

[Rhaoma]

I dont use anything besides rollup to transpile M3E source to js and externalize Lit dependencies. On top of that its a bare-bone HTTP server.
I dont believe it is a case of re-bundling Lit, if I understand you correctly, in that you mean during rollup building i inadvertently pack a version of lit into the M3E source.
Note that i replicate this behaviour on the showcase not in my locally bundled version.

A note on never hitting the breakpoint on line 867 reactive-element@1.6.3/development. It might have something todo with loading sourcemaps.
If i enable them i get the following:

Several sources loaded, (note i only get one source when i locally bundle them), its not unexpected by may be the cause as to why your specific line was never hit.

When writing up the issue i used Firefox and got hits at the aforementioned line 867 reactive-element@1.6.3/development.
However i tested in Chrome where i didn't get any hits at that line.
Instead at line 1552 https://cdn.jsdelivr.net/npm/@lit/reactive-element@2.1.0/src/reactive-element.ts, thus i think it is browser dependent on which runtime is used.
You use Edge?
Enable sourcemaps and reload.
Set conditional breakpoints at:

• npm/@lit/reactive-element@2.0.4/src/reactive-element.ts line 1490
• npm/@lit/reactive-element@2.1.0/src/reactive-element.ts line 1552
• npm:@lit/reactive-element@1.6.3/development/reactive-element.js line 866
• npm:@lit/reactive-element@1.6.3 line 860

You can simplify the condition to:

this.isUpdatePending

Which will just pause.
Below does not pause only logs offending elements:

if(this.isUpdatePending) { console.log(this.localName) };

You can even disable sourcemaps afterwards, the breakpoints remain just in the bundled code (at least on firefox).

Then im sure you'll get hits at one of the lines, and the DEV_MODE will probably be undefined. Check this.localName to see the component.
I have observed this behaviour across at least 2 computers and 2 browsers on the official showcase.

[matraic]

Testing on BrowserStack across macOS Firefox, Chrome, and Safari, as well as local testing on Windows Firefox and Chrome, has not reproduced the issue. However, reviewing some of the components you identified shows use of the ResizeController. This has the following code:

this.#observer = new ResizeObserver((entries, observer) => {
      this.#callback(entries, observer);
      this.#host.requestUpdate();
    });

The requestUpdate here looks to be the likely culprit. Resize observer timing varies by browser so this may be why this occurs on some vs others. More than likely, the requestUpdate is not needed.

[matraic]

In addition, MutationController follows a similar pattern where requestUpdate() is invoked unconditionally. While m3e‑toc does not use a ResizeController, it does rely on MutationController, so this update pattern is emerging as the likely root cause based on the components identified so far.

[matraic]

Fixes have been applied that may address the issue. Keeping this open for now until the changes are verified.

[matraic]

Release 2.1.0 has been published which includes these changes.