Relative ListBindings do not handle busy states automatically

[boghyon]

ODataModel: V2

URL (minimal example if possible): https://embed.plnkr.co/elNMXE/

Steps to reproduce the problem:

1. As shown in the example above: Bind a collection to a child list relatively to a parent control with an expanded ContextBinding. E.g.: items="{odata>ToProducts}" (given ToProducts is a navigation property)
2. In order to see the busy indication, set busyIndicatorDelay to 0 or increase the mock server response delay.
3. Run the app and wait until the busy indication is shown.

What is the expected result?
The listUl section of the list (having relative ListBinding) is busy too.

What happens instead?
Nothing. The busy state is not handled automatically in contrast to the absolute ListBinding.
I guess this is because the refresh event is never fired by its relative ListBinding since resolving relative path returns undefined. I believe this is the intended behavior but the list control manipulates its busy state automatically only if a refresh event is fired.

Any other information?

A simple workaround may be to enable legacySyntax which forces the relative ListBinding to fire the refresh event. But I'm sure that legacySyntax is not intended to be used like that.

---

It would be nice if the busy states are handled automatically regardless whether the binding paths are absolute or relative. I'd like to avoid using setBusy manually on lists with relative ListBindings because not only do I have to manage busy states for them manually but also setBusy(true) shows the busy indicator for the whole list control (including header and footer) instead of just for the listUl section where items are contained.

[Pavan-SAP]

Hi,

Thanks for your report, I was able to reproduce this and have reported it internally 1780230102.
The responsible developer will get back to you.

[goligo]

The reason why the busy indicator is shown in one case and not in the other is not because of absolute and relative bindings. Showing the busy indicator also works for relative bindings. The busy indicator is attached to the request events of the binding. So only if the binding of the list triggers a request, the busy indicator will be shown. In you example the list data is requested as an expanded collection on the element binding, the list doesn't known anything about it and its binding never triggers a request, so it can't show a busy state.

[boghyon]

I'd still rather expand a collection navigation property from the element binding instead of assigning the property solely to the list binding path without having it expanded before. The latter approach has, on the one hand, the advantage of displaying the busy indicator automatically as mentioned before, but on the other hand, it has the following disadvantages:

• The relative list binding has to make another round trip sequentially after the parent has received its data. This can be observed if you take the above example and remove the expand parameter from Page's element binding.
• Because the expand is missing, the navigated collection is never cached which is bad especially for Master-Detail-like apps when the detail element needs to display one of its collections. The detail element itself may be cached for the next time but the request to its collection is sent every time.

As expanding a collection from an element binding circumvents those issues, I'd be happy if you consider to reopen this enhancement request to display busy indicator for such relative list bindings as well even though such bindings don't send any request by themselves.

@goligo @Pvnn

[boghyon]

From my previous comment..

(Without expand in element binding, ...) The relative list binding has to make another round trip sequentially after the parent has received its data.

This is not the case anymore if preliminaryContext is enabled which also enables displaying the busy indicator automatically even though the binding path is relative. Thanks @goligo 👍