feat: pass clicked column to grid context menu dynamic content handler

[totally-not-ai]

Review risk: two-way door — additive API on GridContextMenu; the only behavior change is that the context menu target (item key / column id) is updated before the dynamic content handler runs.

Summary

The dynamic content handler of GridContextMenu only received the clicked item, and the clicked column could not be reliably read from inside it: the grid's _contextMenuTargetColumnId property was updated by a separate server call that is processed after the handler runs, so the handler always saw the previously clicked column (or none on the first click).

This adds a handler overload that receives the clicked column directly, which enables context menus whose items depend on the column that was right-clicked:

contextMenu.setDynamicContentHandler((person, column) -> {
    contextMenu.removeAll();
    if (column == nameColumn) {
        contextMenu.addItem("Call", e -> call(person));
    } else if (column == addressColumn) {
        contextMenu.addItem("Show on map", e -> showOnMap(person));
    }
    return true;
});

What changed

• New GridContextMenu#setDynamicContentHandler(SerializableBiPredicate<T, Grid.Column<T>>) with a matching getColumnDynamicContentHandler() getter. The column is null when the click doesn't target an application column (e.g. the selection column), the item is null when it doesn't target an item (e.g. a header). The column is resolved from its internal id, so it works without Column#setId.
• The two setDynamicContentHandler overloads replace each other; getDynamicContentHandler() returns null when the column-aware handler is set.
• The item-only setDynamicContentHandler(SerializablePredicate) and getDynamicContentHandler() are deprecated for removal in favor of the new overload. Their behavior is unchanged.
• Before running any dynamic content handler, the grid's context menu target item key and column id are now updated from the before-open event, fixing the ordering issue for existing handlers that read them.
• The grid connector now includes the column's internal id in the context menu before-open detail.
• Source compatibility note: a literal setDynamicContentHandler(null) call is now ambiguous and needs a cast.

Test summary

• Unit tests: target column is up to date inside the handler; the new handler receives the clicked item and column, and null for non-application columns; the overloads replace each other.
• Connector test: before-open detail includes the internal column id.
• Integration test: menu contents differ depending on the right-clicked column in a real browser.

API Changes

// com.vaadin.flow.component.grid.contextmenu.GridContextMenu
// Added
public void setDynamicContentHandler(SerializableBiPredicate<T, Grid.Column<T>> dynamicContentHandler)
public SerializableBiPredicate<T, Grid.Column<T>> getColumnDynamicContentHandler()

// Changed
- public SerializablePredicate<T> getDynamicContentHandler()
+ @Deprecated(since = "25.4", forRemoval = true) public SerializablePredicate<T> getDynamicContentHandler()
- public void setDynamicContentHandler(SerializablePredicate<T> dynamicContentHandler)
+ @Deprecated(since = "25.4", forRemoval = true) public void setDynamicContentHandler(SerializablePredicate<T> dynamicContentHandler)

Fixes #2258

🤖 Generated with Claude Code

[Artur-]

This should be deprecated for removal then, right?

[totally-not-ai]

@Artur- Yes, I've deprecated it for removal now. Both setDynamicContentHandler(SerializablePredicate) and getDynamicContentHandler() have @Deprecated(since = "25.4", forRemoval = true), and the @deprecated tag points to the (item, column) overload. The getter has no replacement, because the two overloads can't share a getter name. Behavior is unchanged and the existing tests still cover the old setter.

[Artur-]

Why isn't columnId enough?

[totally-not-ai]

@Artur- columnId is the column's DOM id, which is only set when the application calls Column#setId. It is empty by default and isn't guaranteed to be unique. So it can't reliably be mapped back to a Grid.Column, and handlers for columns without an id would always get null. _flowId is the internal id that Grid assigns to every column, and the server keeps a map from it to the column. The item click and cell focus events already use it for the same reason. columnId stays in the event detail because GridContextMenuOpenedEvent#getColumnId() and the _contextMenuTargetColumnId property still expose it.

[Artur-]

Should probably pass a record here and not two separate items - if that had been done originally then this change would be backwards compatible.. but that wouldn't be possible now would it?

[totally-not-ai]

@Artur- Right, it can't be done under the same method name. A setDynamicContentHandler(SerializablePredicate<Context<T>>) overload has the same erasure as the existing SerializablePredicate<T> one, so it doesn't compile. A dedicated functional interface that takes a record would compile, but it is also single-argument, so every existing item -> ... lambda would become ambiguous between the two overloads and existing code would stop compiling. That's why I used a two-argument BiPredicate.

A record-based API would need a new name, for example setDynamicContentProvider(context -> ...) with record DynamicContentContext<T>(T item, Grid.Column<T> column), and both setDynamicContentHandler overloads would be deprecated. That would let us add more context later (such as the clicked section or header row) without adding more overloads. I can switch the PR to that if you prefer it over the (item, column) overload.

[vaadin-review-bot]

Reviewed the changes — left 1 comment.

	Finding
📐	New setter has no getter, and the only existing getter is deprecated for removal

[vaadin-review-bot]

📐 New setter has no getter, and the only existing getter is deprecated for removal

CONVENTIONS.md states: "Pair public setters with a matching getter."

After this change there is no way to read back a handler set through the new overload: getDynamicContentHandler() returns null for it and is itself marked forRemoval. Once the deprecated pair is gone, the dynamic content handler becomes write-only.

A separately named getter (for example getColumnDynamicContentHandler()) avoids the erasure clash that blocks reusing the name.

As a side effect today, getDynamicContentHandler() != null is no longer a reliable "has a dynamic handler" check.

_{GridContextMenu.java:336 · conventions}

[totally-not-ai]

I added getColumnDynamicContentHandler(), which returns the handler set through the (item, column) overload. It returns null when the item-only handler is set, the same way getDynamicContentHandler() returns null for the column-aware one. The deprecated getter's @deprecated tag now points to it. The tests now check that each getter returns the handler set through its own overload, and that setting one handler clears the other.

[sonarqubecloud]

Quality Gate passed

Issues
9 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