refactor: use the elemental DOM API directly in the client engine

[Artur-]

DomApi.wrap only returned the node itself after the Polymer DOM API was removed, and DomNode and DomElement describe the same native DOM operations as elemental Node and Element. Call sites now use the elemental types directly, which also lets StateTree.getStateNodeForDomNode accept a Node.

DomApiAbstractionUsageTest verified that every DOM call went through DomApi.wrap so that Polymer could rewrite the operation. There is nothing left to rewrite, so the test is removed together with the abstraction.

[Artur-]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in 2356df2.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[github-actions]

Test Results

1 159 files   -   213  1 160 suites   - 213   1h 24m 34s ⏱️ - 2m 27s
7 855 tests  - 2 590  7 806 ✅  - 2 572  48 💤  - 19  1 ❌ +1 
8 174 runs   - 2 590  8 124 ✅  - 2 572  49 💤  - 19  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 747aa93. ± Comparison against base commit 72bfead.

♻️ This comment has been updated with latest results.

[Artur-]

@claude review this

[claude]

Claude finished @Artur-'s task in 2m 15s —— View job

---

Code Review

• Gather context (read the diff and changed files)
• Review the removal of DomApi/DomNode/DomElement
• Review the call-site migrations to elemental types
• Post review feedback

This is a clean, well-scoped refactor. I confirmed the premise holds: DomApi.wrap(node) was literally just (DomElement) node, and DomNode/DomElement were @JsType(isNative = true) interfaces mirroring the native DOM methods that elemental.dom.Node/Element already expose. So every call-site migration is behaviorally equivalent — nothing is lost by dropping the abstraction.

What I verified ✅

• No dangling references. Grepped flow-client (main + test-gwt) for DomApi, flow.dom.DomNode, flow.dom.DomElement, DomTokenList — zero matches. Deletion is complete and won't break GWT compilation.
• NodeList API swap is correct and consistent. DomNode.getChildNodes() returned a JsArray<Node> (.length() / .get(i)); the code now uses elemental.dom.NodeList with .getLength() / .item(i). This matches the pattern already used elsewhere in the module (ResourceLoader.java:588, and the GWT tests at GwtBasicElementBinderTest.java:604,639,840), so it's the established idiom, not a new one.
• classList swap is correct. element.getClassList() returns elemental.dom.DOMTokenList, and add/remove(String) line up with the old DomTokenList methods (SimpleElementBindingStrategy.java:1567,1575,1580).
• Comparison semantics preserved. StateTree.getStateNodeForDomNode still compares via Node.isSameNode(...) (===), so widening the parameter from DomNode to Node is purely a type relaxation with no functional change — and it's a genuine ergonomic win, as the description notes.
• Live-list handling is safe. In removeAllChildrenAfterReplacement, the live NodeList is snapshotted into replacedChildren before any DOM mutation, matching the prior behavior (the old JsArray<Node> was equally live).
• Removing DomApiAbstractionUsageTest is justified. Its sole purpose was to assert every DOM operation routed through DomApi.wrap so Polymer could rewrite it. With Polymer's DOM API already gone (chore: remove Polymer 1 DOM API and HTML import loading #25145), there's nothing left to enforce, so there's no behavior to re-cover elsewhere.

Minor observations (non-blocking)

• PolymerUtils.getChildIgnoringStyles — explicit (Element) parent cast (PolymerUtils.java:615). Previously DomApi.wrap(parent) was an unchecked cast to a native @JsType; the new (Element) cast is also unchecked in compiled JS, so there's no runtime change. It only matters in GWT dev mode, and getChildren() was already Element-only, so no regression. Fine as-is — just noting the one spot where a cast became explicit.
• Fully-qualified elemental.dom.NodeList is used inline (rather than imported) in SimpleElementBindingStrategy and ExecuteJavaScriptElementUtils. This is the right call — both files already import com.vaadin.client.flow.nodefeature.NodeList, so the FQN avoids an ambiguous import.
• CI signals are expected noise. The SonarQube "0% coverage on new code" gate fails simply because this PR adds no new executable logic (it's deletions + type substitutions); the existing GWT binder tests already exercise these paths and pass. Nothing to act on.

Verdict

No correctness, security, or performance concerns. The change reduces surface area (−668 LOC) with equivalent behavior and even improves an API signature. Nice cleanup. 👍
• remove-dom-api