Add support for @click.right event on UTable rows to enable context menus

[Ozan-Deniz]

Description

Hello,

I've spent the last couple of hours trying to implement right-click functionality on UTable rows. I've reviewed existing issues but couldn't find a solution that fits this need.

What I want to achieve is to show a UContextMenu with actions related to the clicked row when the user right-clicks on it.

Currently, there is no way I could find to detect right-click events on individual rows along with their row data. If UTable had a #row slot or a dedicated @click.right event that provides the clicked row’s data, this would be easily achievable.

If there is any workaround or method to implement this right-click behavior on rows with access to row data, I would really appreciate if someone could share it.

Thank you!

Additional context

No response

[J-Michalek]

I think we could add another prop onContextMenu to handle the contextmenu event on a row, but that would not work with UContextMenu as it requires a trigger element, you could do it with UDropdownMenu and provide the event.target to it as the reference, but it still wouldn't be perfect as the dropdown menu would be positioned againts the bottom of the row and not against the cursor position.

We could expose the cells td as slots with RekaUI's Primitive component, that would allow the user to bind their own event handlers/attributes on the cell itself. As for exposing a slot for rows that would be a little harder to use as you would have to iterate over the data yourself to create the underlying cells yourself - doable, but more hands on for the user. What do you think? @benjamincanac

[Ozan-Deniz]

I think we could add another prop onContextMenu to handle the contextmenu event on a row, but that would not work with UContextMenu as it requires a trigger element, you could do it with UDropdownMenu and provide the event.target to it as the reference, but it still wouldn't be perfect as the dropdown menu would be positioned againts the bottom of the row and not against the cursor position.

We could expose the cells td as slots with RekaUI's Primitive component, that would allow the user to bind their own event handlers/attributes on the cell itself. As for exposing a slot for rows that would be a little harder to use as you would have to iterate over the data yourself to create the underlying cells yourself - doable, but more hands on for the user. What do you think? @benjamincanac

Thank you for the detailed explanation!

I believe you meant exposing the 'tr' rather than the 'td', since right-click interactions or hover effects usually apply to the entire row. That said, exposing both rows and individual cells via slots (or via something like RekaUI's Primitive) would open up a lot of flexibility.

Being able to bind custom event listeners (like mouseenter, contextmenu, or even dblclick) directly on rows or cells would make it much easier to implement advanced UX patterns. A few real-world use cases that come to mind:

• Right-click (contextmenu) on a row to show a context menu with actions like "Edit", "Duplicate", "Assign Tag", etc. This is what I’m trying to implement right now.

• Hovering over a row to show a tooltip or preview card (e.g., a customer profile or product preview).

• Double-clicking a row to open a detailed view or enter inline edit mode.

• Shift+click or Ctrl+click to trigger custom selection behavior outside of the built-in selection logic.

Even if exposing full row customization requires manually iterating over data, having that level of control is still worth it for many use cases. Ideally, both lightweight props for simple handlers (@contextmenu, @mouseenter, etc.) and lower-level slot-based customization could coexist.

Also, just to add—cell-level event handling is already somewhat possible, since we can customize each column using the cell property inside the columns array. That way, we can render custom content in a cell and attach event listeners (like @click, @contextmenu, etc.) directly to the elements we return there.

Thanks again for considering this!

[J-Michalek]

Just to clarify I actually meant to expose everything we can, just had some reservations about the tr elements being exposed, but I guess more options is always better even when some DX may be lost in the tradeoff as long as it stays optional.

[phicoder]

@Ozan-Deniz For now a workaround would be this:
#3655 (comment)

Hope it helps!

[J-Michalek]

I think we should progress on this as it is becoming stale, I think there is no reason not to expose more slots, but I will let @benjamincanac decide.

This is also somewhat related to #4393 as the author of the would atleast be able to implement their requested feature (table cell selection) themselves if the cells were exposed via a slot.

Note: There is already an option to provide content of the cell using a slot, but these use cases require access to the wrapping td element.

[benjamincanac]

I've found a way to make it work in latest commit, it's a bit similar to #3655 (comment) but now you will have access to a @contextmenu event to determine which row was clicked: https://ui.nuxt.com/components/table#with-context-menu