General recommendation is to delay the addition/removal decision and perform manipulation only at the end. Also, look at the Java code generated for the rule form, identify better/faster alternative and configure the activity/data transform accordingly. Appending/removing to/from a page list at the end is always faster.
I was just talking to @LantzAndreas about a related issue.
How do you present 300 rows of data to user without overwhelming them (or turning into Excel / Sheets).
I would suggest the solutions align here. Can you not break up the process/steps to incrementally work on X rows at a time? Something that is manageable for a user? This way its more User Friendly but also gives you less technical issues trying to create hundreds of records whilst user sits and waits?
@LantzAndreas did you trial any of the approaches that you might be able to share leanring or vidoes of?
Curious: How does the user know what value to supply in the “count” field? Are they looking at a paper form? Or is this value coming from another system?
The client operates in a contractor-like model, where a count is derived based on specific business logic. This count can be considered as a calculated field.
We use this calculated total count on the subsequent screen to dynamically determine the number of rows (N) to be displayed in the Address table. Accordingly, the system renders N blank address rows, allowing the user to enter all the addresses currently available to them.
However, the design also accounts for flexibility in the user journey. In scenarios where the user does not have all address details at that point in time, they can choose to skip entering them initially and complete the remaining address information later as part of the ongoing case lifecycle.
Please let me know in case any more details are required. Thank you
Would it be possible for you to treat this as a 2-model design i.e. stop treating this as a large editable clipboard-backed Page List that must be fully materialized on every Count change and rather have a persisted data model for the number of rows the user has entered and a UI View that only displays a limited set of rows?
Use an optimized table or grid-like presentation with pagination/progressive paging, and keep the entered row data in a backing store keyed by row index. ‘.Count’ stores the requested total rows. A list Data Page returns only rows for the requested page window, such as rows 1–50, 51–100, and so on and Each row has a stable key such as ‘RowNumber’. If a row does not yet exist in storage, the loader can synthesize an empty row DTO for that index.User edits save back to the underlying case data or a temporary child structure keyed by row number.
This avoids creating hundreds of clipboard pages just to satisfy UI rendering
I’ve also seen this done in UI Kit app, where they had the same problem. We had data instances created already, that were “blank” and then the case claimed the number it needed so it could be used in the case. This also has the added benefit of a separation of concern between the case and the address, if you have the need to edit addresses from other cases or even using CRUD actions on data (“delegated data” in UI Kit)
It is a little more complex but would avoid creating pages on the fly. I mention this last as its my least favourite option, but I have seen this used successfully.
@MarcCheong Unfortunately in the situation I have there was a strict requirement to “show everything in the same place”. I would much rather solve the basis, that the amount of items is too much. I think the cognitive load for users is too much regardless which presentation/segregation option you go with, if you have hundreds of rows in the same case. Especially if there is a lot of data to fill per item.
For my situation, we are going with the approach of using OOTB table with modal for edit when it comes to the assignment. For showing the data in the summary panel tabs, we are evaluating the usage of a custom DX layout that is repeating layout style with the added capability of:
Most rows are collapsed by default, a certain number can be expanded by default for the initial viewing of the list
Expanding further rows collapses earlier ones. = means just a certain number of rows expanded at any given time. Helps reduce cognitive and performance load.
Is deferred load by default, so that the list items only load when you open them. When they auto-collapse, they also “un-hook” from the DOM.
The reason for going with different approaches were:
Try to keep it as much OOTB as possible, deviate where needed.
Editing vs reviewing experience doesn’t have to be the same if different approaches make sense. For us there is the additional fact that it’s often different personas editing vs reviewing the items.
The custom DX layout above was considered for the assignment view, but we foresee issues of data persistence when un-hooking items - would Constellation remember the values or simply discard them? It is likely it will behave in a way similar to trying to update and save a read-only field on a view. This problem is a moot point if only using for viewing purposes.
nice suggestion