[Tests/Perf] Disable 100ms timeout in each waitForChanges()

[maxpatiiuk]

Priority impact

p - medium

Test type

E2E tests

Which Component(s)

all

Unstable Tests

Blocked by #10310

Stencil's implementation of waitForChanges() had some issues.

• They scout the entire DOM tree in search of web components that have not yet been loaded
  • Note, they only check for not-loaded components - Stencil didn't check whether component is re-rendering, only whether it's loaded.
• Maybe as a result of the above, they set a 100ms timeout in each waitForChanges()

Lumina provides a backwards compatible waitForChanges() with two improvements:

• In dev mode, maintains a list of WeakRefs to all created components so that we can cheaply detect which of them are still loading/updating.
• In waitForChanges() ensure each component is loaded if not yet loaded. If it's already loaded, ensure all updates are completed.
• Do not wait 100ms, but do allow a config option to add back this delay for compatibility with Stencil - see below for more info.

---

With the 100ms wait, Calcite E2E tests run in Lumina+Vitest at about the same speed as in Stencil+Jest.
Without 100ms wait, Calcite's E2E tests run ~40% faster.

BUT, Calcite's E2E tests do not disable animations (default duration seems to be 150ms in many places) and some tests are asserting the element computedStyles after animation is completed.

While Stencil's waitForChanges only waits for 100ms, the fact that you always call waitForChanges twice in assertThemedProps(), made it wait 200ms, thus the test was passing.

If I remove the 100ms delay, these tests start to fail. I added it back for now to simplify the migration.

TODO:

• After migrating to Lumina, you may choose to disable the 100ms delay using a config option and refactor the failing tests.
• You can also look for and remove redundant calls to waitForChanges. For example, the waitForChanges call here is needless since newE2EPage already does it:

  calcite-design-system/packages/calcite-components/src/tests/commonTests/utils.ts

  Line 42 in 9312e29

  await page.waitForChanges();

• Similarly, the following E2EElement methods automatically await changes, so you don't have to:
  • click, focus, hover, press, tap, type
  • For example, this is redundant:

    calcite-design-system/packages/calcite-components/src/tests/commonTests/formAssociated.ts

    Lines 423 to 424 in 42c1329

    	await submitButton.click();
    	await page.waitForChanges();

---

P.S.: I imagine more speed ups from transition to Vitest browser mode as then it would reduce the need for each component interaction to be a separate async action (you would just be calling DOM APIs directly), and reduce the need to sync the HTML content between the browser and node.js after every change.
Thus, you may choose to do bare minimum performance optimization at the moment, and wait for migration to Vitest browser mode instead.

Test error, if applicable

No response

PR skipped, if applicable

No response

Additional Info

No response