ui5-webcomponents icon indicating copy to clipboard operation
ui5-webcomponents copied to clipboard

TableSelection: include selected row/s in `change` event

Open Lukas742 opened this issue 1 year ago • 5 comments

Feature Request Description

When calling the change event of the ui5-table-selection component, I couldn't find a way to get the selected row/s, other than querying the DOM using the selected keys myself.

In the previous table you could use two detail entries (see below) for this, but it seems like the current implementation is missing them.

type TableSelectionChangeEventDetail = {
	selectedRows: Array<ITableRow>,
	previouslySelectedRows: Array<ITableRow>,
}

Example: https://stackblitz.com/edit/github-ltccua-duajhg?file=main.js,index.html,package.json

Also, it's not clear by the documentation what the recommended way to retrieve the rows is, maybe adding it to the example would help as well.

The current TableSelection is key-based, therefore each row requires a key-attribute to be uniquely identified.

This part could also be formulated more clearly by pointing out that the attribute is called row-key and not just key.

Proposed Solution

There should be an easy way to get the current selected row, all rows that are currently selected and maybe even the previous selected rows. Imo, the first two are essential, the last one (previous selected) is optional.

Proposed Alternatives

No response

Organization

UI5WCR

Additional Context

No response

Priority

None

Privacy Policy

  • [X] I’m not disclosing any internal or sensitive information.

Lukas742 avatar Aug 12 '24 13:08 Lukas742

Hello @SAP/ui5-webcomponents-topic-core,

Please checkout this feature request.

Best regards, Boyan

unazko avatar Aug 12 '24 15:08 unazko

Hi colleagues,

another thing that would be very helpful, especially for React developers, is that the custom behavior of the change event can be prevented. In React it's common to "fully control" a component, meaning that it's state (in this case the selected state of the rows) are only controlled by the application, not by the component itself.

Proposed Solution

When calling event.preventDefault() in the change handler, no internal selection should happen. Since it's necessary to know which row has been selected by the user, the event should also return the currently selected row.

If I should open another feature request for this, please let me know :)

Lukas742 avatar Aug 13 '24 12:08 Lukas742

@simlin @aborjinik @DonkeyCo could have a look, this is a request for the v2 Table web component.

ilhan007 avatar Sep 02 '24 07:09 ilhan007

Hello @Lukas742,

the idea of using a top-level single "selected" key-based property was to decouple the selection from the actually available rows. In combination with growing or row virtualization, which we currently started to evaluate, only a subset of rows are available in the DOM.

To introduce an API in addition which is row based seems to conflict with this approach.

Making the role of the "row-key" property more prominent in the documentation is for sure possible. As far as I remember the name of the property was also changed during the past month. Maybe the one ore other place was forgotten.

The requirement to preventDefault of the selection reminds of #5662. What is the exact usecase for this? The Fiori guidelines follow the pattern to not disable or prevent certain rows from being selected. Instead the prevention and checks should happen on the actions which are based on the selection (see #5662). Therefore we do not have such a functionality in UI5 so far.

Best Regards Jens

simlin avatar Oct 21 '24 14:10 simlin

Hi @simlin

thank you for your answer, it makes things clearer to me.

the idea of using a top-level single "selected" key-based property was to decouple the selection from the actually available rows. In combination with growing or row virtualization, which we currently started to evaluate, only a subset of rows are available in the DOM.

To introduce an API in addition which is row based seems to conflict with this approach.

I agree; with virtualization, exposing DOM nodes in the event is not really feasible. My main concern now is that this should be outlined better, as I found it wasn't straightforward to implement a typical selection scenario in the most performant way using the ui5-table.

I've created an example to illustrate what would be necessary to implement this on the app side in a React app using our wrapper: https://stackblitz.com/edit/ui5wcr-table-features-62h1dj?file=src%2FApp.tsx

Please let me know if I used the API incorrectly or if there's something that can be handled differently. I've also added comments highlighting potential pitfalls when implementing this behavior.

The requirement to preventDefault of the selection reminds of https://github.com/SAP/ui5-webcomponents/issues/5662. What is the exact usecase for this? The Fiori guidelines follow the pattern to not disable or prevent certain rows from being selected. Instead the prevention and checks should happen on the actions which are based on the selection (see https://github.com/SAP/ui5-webcomponents/issues/5662). Therefore we do not have such a functionality in UI5 so far.

Since the table can be fully controlled by the selected property, with no "internal" state updates (selection) occurring, I withdraw this request. The only use case I can think of now is if the selection should be gated, for example, by a confirmation dialog. However, since this can be achieved by resetting the selection within the actions of the dialog, this is also something that doesn't necessarily require preventing the default behavior.

From my side, this feature request can be closed. :)

Lukas742 avatar Oct 23 '24 12:10 Lukas742

:tada: This issue has been resolved in version v2.8.0-rc.3 :tada:

The release is available on v2.8.0-rc.3

Your semantic-release bot :package::rocket:

ui5-webcomponents-bot avatar Feb 27 '25 08:02 ui5-webcomponents-bot