Compared to RP9, I find that any calls to edit row data in repeater tables is much slower and results in an annoying delay in the browser preview. What used to be fairly instantaneous response when performing an action that results in table data being updated and reloaded in RP9 now takes at least a couple of seconds to respond in RP10, which negatively impacts the experience while using the prototype. This is on a late 2016 MacBook Pro running MacOS 10.14.6 using the latest Beta 10.0.0.3814, if that helps.
Hi jkuo, thanks for reporting this. Just to clarify, the performance issues you are seeing are only happening when using the “Edit row data” interaction in the browser and not when editing the repeater dataset in RP, is that right?
So far I haven’t been able to reproduce a difference in that performance between 9 and 10, but I would like to investigate this further. Do you have a file exhibiting the issue that you would be able to share with us? If so, you can post it here or email it to firstname.lastname@example.org and we will look into it! A version 9 copy of the file would be particularly helpful if you have it so that we can compare the difference directly between versions.
@Julie_Axure, thanks for following up! I discovered through more in-depth testing that the slowdown doesn’t seem to be directly caused by the edit row data call, but rather some additional code for resizing some UI elements that I had added into the Item Loaded function of a repeater table since I started using the RP10 Beta. Please correct me if I’m wrong but I believe any call to edit row data will also cause the Item Loaded function for the repeater to be executed as well.
Removing the Set Size function calls for just 4 widgets from the Item Loaded function seemed to improve the performance significantly, so it would appear that the real culprit would be the Set Size function calls causing the significant delay. Unfortunately, it’s a function I need to use to set the size of the container appropriately around text I am loading from the table which could be of varying lengths. Is there anything that can be done to improve the performance of the Set Size function?
Without looking at your prototype, it’s hard to prescribe a re-size option but if you use the “Label” widget, you can set Padding and play with the “Fit to text length” and “Fit to text height” toggles a bit (buttons above Widget Style in /Style/) - I want to say I used that for the bubbles in an interactive/dynamic chat-app prototype I made once.
Also maybe try adding a condition to the re-size interaction for rows that need to be re-sized? I’ve never done it, but maybe it’ll avoid running some unnecessary logic and impacting performance.
Would be really cool if we could “Update Marked” and avoid re-running the whole repeater.
You’re correct, btw, that any “Update Repeater” action to change row contents will modify the dataset and re-run OnItemLoaded on every row of the repeater.
Thanks for the additional information, jkuo! I was able to reproduce slowness in the HTML when an Item Loaded action sets the size of widgets in a fit to content repeater (and if this action requires a resize of the repeater itself), so I’ve filed a ticket for us to look into any possible optimizations around that workflow.
As JimJam mentioned, it’s difficult to say without looking at your prototype, but you might be able to find a way around the set size actions if you’re using fit to content options on the text widgets inside the repeater. One of the improvements in 10 is to apply fit to width/height settings in the prototype even when text is being set dynamically, like in repeaters.