refactor: allow grid header and footer renderers to run multiple times

[vursen]

The grid web component is moving to rendering its header and footer declaratively with Lit (vaadin/web-components#12134). With that change, header and footer cells can be re-created, which re-runs the column renderers. The connector wrapped these renderers in singleTimeRenderer, so a re-created cell would stay empty.

The sorter element is now cached between renderer runs: re-creating it on every run would reset the sort direction and send a needless sorters-changed event to the server.

Part of vaadin/web-components#10789

[vaadin-review-bot]

Reviewed the changes — left 1 comment.

	Finding
👀	The new "renderers run multiple times" behavior and the vaadin-grid-sorter caching have no test.

[vursen]

@claude Investigate why single time renderers were added in the first place.

[claude]

Claude finished @vursen's task in 2m 34s —— View job

---

Why singleTimeRenderer was added

I traced the connector's git history. singleTimeRenderer was introduced in #4025 — refactor!: remove template usage from grid header and footer (Sascha Ißbrücker, Nov 2022), commit d790e87b.

What that PR did

It replaced the old Polymer <template>-based header/footer rendering with the grid web component's imperative renderer API (column.headerRenderer / column.footerRenderer). As part of that, the header/footer content stopped being an HTML template string and became a live DOM node owned by Flow — headerComponent.getElement() (or a plain text string) — passed straight to the connector:

// AbstractColumn.java (introduced in #4025)
grid.getElement().executeJs(
    "this.$connector.setHeaderRenderer($0, { content: $1, showSorter: $2, sorterPath: $3 })",
    this.getElement(), headerContent, showSorter, sorterPath);

The connector renderer, back then, also cleared the cell on every run:

column.headerRenderer = singleTimeRenderer((root) => {
  root.innerHTML = '';            // wipe cell
  const sorter = document.createElement('vaadin-grid-sorter');  // fresh sorter each run
  ...
});

Why it was wrapped in singleTimeRenderer

With the imperative renderer API, the grid web component may invoke a cell's renderer more than once during that cell's lifetime. Letting it re-run was undesirable because each run would:

1. Recreate the vaadin-grid-sorter — discarding the current sort direction and firing a needless sorters-changed round-trip to the server.
2. Clear and re-append a Flow-managed node (root.innerHTML = '' then re-append content). Flow owns that node's lifecycle independently, so having the web component repeatedly wipe and rebuild the cell was pointless churn and risked fighting Flow's own DOM management.

Since header/footer content only legitimately changes when Flow calls setHeaderRenderer/setFooterRenderer again — which installs a fresh renderer closure — rendering once per closure was the simplest safe behavior. singleTimeRenderer enforced exactly that: run the wrapped renderer on the first cell paint, then no-op.

Why this PR reverses it

The web component is moving to declarative Lit-based header/footer rendering (vaadin/web-components#12134), where header/footer cells can be re-created. A re-created cell needs its renderer to run again to be populated — with singleTimeRenderer, re-created cells would stay empty. So the constraint that made single-time rendering safe no longer holds.

The one original benefit worth keeping — not recreating the sorter — is preserved by caching it in the closure instead:

let sorter;
column.headerRenderer = (root) => {
  if (showSorter) {
    sorter ??= document.createElement('vaadin-grid-sorter');  // reused across runs
    ...
  }
};

So the current PR keeps the sort-direction / no-extra-round-trip guarantee that motivated the original code, while dropping the "render once" restriction that the new declarative rendering makes incorrect.

Note (unrelated to your question): the review bot's point still stands — there's no WTR test exercising a renderer running twice with a re-created root, so a regression to const sorter = ... or to a single-run guard would ship undetected.
· branch grid-rerunnable-header-footer-renderers

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud