Data Table: Show loader for specific table line instead of blocker for entire table

[DzmitryTrubchyk]

Requestor: EPM-PRL

As is

In case bulk selection and applied actions, table changes to Blocker state

Proposal

Show loader for specific table line instead of blocker for entire table

[DzmitryTrubchyk]

Comments from Design Leads:

• it's needed to disable the whole row, that is in loading state
• do we need cases when the single cell should be with loader? Or the whole column?
• if it's reloading the whole row, how's about showing loader not instead of checkbox, but in the center of row, showing that it's disabled now?
• do we need state to show where loading is already completed? Like highlighting new data to distinguish between data that hasn't been updated yet?
• in general, let's add "loading" as additional state for components. E.g. for inputs, for cells, for rows, for columns - kind-a new type of skeleton, contextual loader

[ilya-gorchakov-epam]

Resolution: Added to UUI backlog, as good UX proposal, but postponed due to high efforts & small potential adoption

[jakobz]

TLDR: This UX pattern can be difficult to implement in general. We can recommend this pattern only on screens where we can afford the best UX possible, like heavily used end-user-facing screens. We don't recommend using this pattern at back-office/admin pages.

This pattern lets user fire a long-running operation, and let user continue using UI: changing filters, navigating through pages, select other rows, etc.

A lot of corner-cases might happen due to this:

• if batch operation affects the list (e.g. we want to remove processed items) - we need to reload the whole list. But what if a user had changed sorting/filtering/page while we were processing the request? We might receive an updated list along with response, but can't display it - as it's for a different sorting/filtering/page
• if there are other controls allowing to edit the rows being processed. E.g. a dropdown menu, allowing to set Status. We'd need additional care to not overwrite one operation with another one running in parallel.
• two batch operations can be fired at the same time. There are no guarantees that the server response for the first one would arrive before response for the second one.
• I can continue with more cases. However, in general - dealing with asynchronous operations in parallel is hard.

For sure, certain tables can be dead-simple, with no filtering/sorting, and only with batch operations on them. And the pattern described might look as a good fit. However, the same table can be staffed with features in the future. And all these changes would need to consider this asynchronous batches, and work-around all related problems.