Skip to main content

When using a table with pagination with row actions that have conditional display logic the pagination slows down until the table (and entire page) become unusable/unresponsive. The more conditional row actions there are the quicker the slow down occurs, seems to be some background Skuid processing of row actions that causes decreasing performance until the page becomes unresponsive.


The following simple page reproduces the problem, just page through the table back and forth a few times and notice the slow down. Only 3 row actions but when we use our real Skuid page with 10 row actions that are driven off a simple status field the page rapidly becomes unusable.


Using Skuid Salesforce 12.1.7 but looks like later releases don’t address this issue. No real workaround, sometimes have to reload the page after using it a few minutes


 <skuid__page unsavedchangeswarning="yes" personalizationmode="server" showsidebar="false" showheader="false" uniqueId="sk-Yd3-1881" globalfeedbackenabled="false"> <models>
<model id="Accounts" limit="99" query="true" createrowifnonefound="false" datasource="salesforce" sobject="Account">
<fields>
<field id="RecordTypeId"/>
<field id="Name"/>
</fields>
<conditions/>
<actions/>
</model>
</models>
<components>
<skuid__table model="Accounts" uniqueid="sk-YdF-4265" mode="read">
<fields>
<field id="Name" uniqueId="sk-YdF-4550" uniqueid="sk-YdF-4649"/>
</fields>
<filtering enableSearch="false" instantSearch="false"/>
<rowActions>
<action type="multi" label="a" uniqueId="sk-YdH-5080">
<renderConditions logictype="and">
<renderCondition type="fieldvalue" operator="!=" enclosevalueinquotes="true" fieldmodel="Accounts" sourcetype="fieldvalue" field="Name" fieldtargetobjects="Account" value="a"/>
</renderConditions>
</action>
<action type="multi" label="b" uniqueId="sk-YdI-5244">
<renderConditions logictype="and">
<renderCondition type="fieldvalue" operator="!=" enclosevalueinquotes="true" fieldmodel="Accounts" sourcetype="fieldvalue" field="Name" fieldtargetobjects="Account" value="b"/>
</renderConditions>
</action>
<action type="multi" label="c" uniqueId="sk-YdJ-5354">
<renderConditions logictype="and">
<renderCondition type="fieldvalue" operator="!=" enclosevalueinquotes="true" fieldmodel="Accounts" sourcetype="fieldvalue" field="Name" fieldtargetobjects="Account" value="c"/>
</renderConditions>
</action>
</rowActions>
<massActions uniqueId="sk-YdF-4650"/>
</skuid__table>
</components>
<resources>
<labels/>
<javascript/>
<css/>
<actionsequences/>
</resources>
<styles>
<styleitem type="background" bgtype="none"/>
</styles>
</skuid__page>

Stephen,

Thanks for the great info, I have built a repro page using your XML and logged a ticket with our product team.

Clark


Thanks for logging the ticket, just wanted to check if there was an update on this because we recently upgraded to 12.2.14 and this issue seems to have gotten worse. The pagination slows down even more quickly and becomes unresponsive to the point that a reload/or closing the tab is not possible. You then need to wait until Chrome times out the page with the “Aw, Snap!” error page, not a great user experience 😦

I did see that 12.2.15 came out last week so tried it in a sandbox with no luck. It definitely seems to be an issue with conditional row actions. If you take the example page with the issue and remove the row actions the page runs smoothly with no performance issues.


Our users are complaining so we’re looking at our last resort option where we redesign our pages to remove/reduce row actions :-c


Any help would be appreciated, not sure why other Skuid customers are not seeing this, maybe they don’t have apps with tables and multiple conditional row actions. Our app needs them to allow users access to many different row actions depending on record state and user attributes which I would’ve thought was a common scenario.


Stephen,

Let me check into this and see if I can get an update from Engineering. Sorry for the delay in response with an update.

Thanks for your patience! 


Ok thanks for looking into this Clark. I take it this will not be fixed in the next week or next maintenance release so we will have to find a work-around? Just need to make a call here as we are about to release another version of our app.


Stephen, we have a fix that will be out shortly as part of the next maintenance release-- I am not sure on the release date at this time, should be soon though. I will update here as soon as it is available.

Thanks again!


Nice one Clark, thanks for chasing this one down and to the team for prioritizing a fix. Look forward to it!


Can confirm v12.2.17 fixes this issue. Many thanks to Clark and the team for resolving this! 🙂


Great news Stephen! Thank you for bringing this to our attention!


Reply