Lazy loading of Change History

[mnkiefer]

• Decision to go for i. @UI.PartOfPreviewannotation solution
• Keep as TODO for now as this requires fixes from Fiori, see: https://support.wdf.sap.corp/sap/support/message/2370110305

---

Options for lazy loading in the UI for Change History

We want to lazy load the Change History table on a Fiori Object Page as this table can have a large number of entries which we only want to see/search on demand.

Requirements

In implementing this, we have the following restrictions:

1. We are restricting ourselves to an Object Page:

   Unlike the Go Button from the List Report Page, an Object Page treats lazy loading different according to the number of items, where the Change History table would fall into the last category (as marked by ➡️ ):

   Lazy Loading type	# Items
   Lazy Loading Behavior (“More” button)	< 100
   Tab Navigation	> 100 but <= 400
   ➡️   Navigation to Another Page	> 400

2. We are restricting ourselves to using only Fiori annotations

   That means, no changes to the manifest.json, which contains most of the controls that we need, such as navigating to a separate Page (component), using another template (List Report), etc. that would support the extra features we need.

In general, any solution we take should not violate the Fiori guidelines and stick to the possible (existing/customized) features of the floorplan (see Object Page) as designed.

Possible solutions

To implement a solution within the realm of requirements (from above), we can only do two more things to influence the table loading: By showing/hiding the entire table or by implementing a button that only loads the data for that table on demand.

   i. Using @UI.PartOfPreview
   ii. Using @UI.Hidden on facet
   ii. Using @UI.Hidden on columns
   iii. Using an Action to set $skip, $top

---

i. Using @UI.PartOfPreview

• Disabling @UI.PartOfPreview hides the facet initially:

  

• Provides the buttons Show More/Show Less Buttons to show/hide it on demand:

  

Important

COULD USE as long as filter/search erroneous behavior is fixed on page refresh
Could this be due to the following restriction on facet target?

---

ii. Using @UI.Hidden on facet

• Hiding the entire facet will stop data from loading automatically. We would then need an action button at the top of the Object page to toggle (show/hide) the facet on demand.

  

Important

COULD USE as long we can set @UI.Hidden dynamically so that the Table as the button is pressed.

---

iii. Using @UI.Hidden on columns

• Hiding all columns does not have this issue (we still have a button), but the user might wonder why there are no default columns set to display:

  

Warning

SHOULD NOT USE due to misleading message in the UI (we cannot change this text)

---

vi. Using an Action to set $skip,$top

• We display the table by default but initially set $top = 0. On pressing an action button "Show Changelogs", we could send a request to OData to retrieve the data, but with extra parameters that reset $top/$skip to their defaults. The user might still be confused by the default message 'No items available'.

  

Warning

SHOULD NOT USE, as it interferes with standard OData calls.

---