Things to Avoid for Repeating Pages/Sections
Most of the these apply to repeating pages as well as repeating sections.
Nesting Repeating Sections
A repeating section will multiply everything that is inside it. If the repeating section has lots of data and questions, and then you include this repeat within another repeat, you are multiplying the multiplier. This degrades the performance exponentially, especially where data is involved.
Fragments in Repeating Sections
The use of fragments is for convenience of design and not for performance. If a repeater contains 50 questions, the performance impact will be the same whether the questions are in a fragment or not. Adding an additional row will be just as slow as adding that number of additional questions outside a repeater or fragment.
Data Sources Inside Repeating Sections
A data source inside a repeating section will be its own data source each time. If the data source is slow or accesses a large amount of data, this performance impact will be multiplied by the number of repeats. In addition, the practices relating to complex logic in repeat rows also apply to the use of data sources in repeat rows.
Number of Questions in a Repeat Row
Adding a repeat copies all of the questions in a section. If there are a lot of questions, this may impact poorly on performance, as it has the same effect as if those questions were added directly.
Multiple Repeating Sections on a Page
For usability, multiple repeating sections on a page can result in a large number of questions that a user needs to answer resulting in a poor user experience.
Repeated Documents and Content Library Items
Documents and content library items that are repeated on the basis of a repeating section or page will be generated and stored individually for each row. Therefore, if it is a complex or large document or complex and large, this will have performance and space implications.
Complex Logic in Repeat Rows
The SmartIQ formula engine is capable of carrying out a range of complex logic. The use of such logic inside repeating rows can result in this logic needing to be recalculated anytime a row is added or updated, or anytime a value with a dependency related to one of those rows is changed.
Depending on the number and nature of the questions involved, this recalculation may take an unexpectedly long time, especially when multiplied exponentially by repeat rows. A recalculation may also be caused by data earlier in the form changing. Therefore, adding a large number of rows to the repeat and then altering those values may have an unexpected performance impact.
Actions can also be repeated and, like large or complex documents, should be noted that a long running action or one that has a long timeout or large number of retries will significantly increase the runtime of the form.
Updated almost 2 years ago