All of my interfaces start to suffer after ~1,000 - 1,500 lines of code or more. By 'suffer' I mean... It becomes extremely unbearable to design an interface in either 'design mode' or 'expression mode.' When I click on a component, or try to go from 'design' to 'expression' modes, saving, checking performance - basically every imaginable action I try to perform is delayed by 10+ seconds. I don't think this is a client side issue. I have 2 other teammates on my team facing similar issues and we all have good internet, using Chrome, etc.
When clicking and waiting 10-15seconds for the 'performance' screen to load, it does show that the interface is decent performing, but when designing it... it is abysmal. Here is copy/paste of all the components on my interface:
Shows 135 ms performance, but I'm literally incapable of designing it any further do to GUI lag/performance issues in design/expression mode.
What am I doing wrong?
Discussion posts and replies are publicly visible
For the sake of testing - I removed a lot of column layouts and put all my components within just a handful of column layouts, as well as a bunch of other components. 200-something components down to 121 components, but I am still experiencing nearly 10 second load times when performing actions.
For the sake of testing - I went and removed most of my column layouts and condensed components into only a handful of column layouts and I instituted using more side-by-side components. As a result I knock down my total component count from 211 to 121. I am still experiencing significant lag while trying to develop.
The code also went from 3500 lines to ~2000 lines.
Are you on premise / any system administrators to review performance?
Typically I only see this type of performance hit when slow a!queryEntity() calls are involved.
I'm not sure if I have too much to provide here, other than suggesting you break your large forms down into smaller interfaces, then reference them together from one parent interface.
The environment is not on-premise. If the latter part of your message is true, then this concerns me. We literally have thousands of fields worth of 'forms' we need to build (intense process driven/data capture driven stuff over here). What's concerning is the fact that if the second part of your statement is true/best practice, to build many interfaces and compile them together, then my main concern is having hundreds of interfaces interlaced together and the chaos involved in managing all the objects.
Breaking down large forms into multiple components does not mean to put each field into its own component.
I think it is worth doing an analysis on how you want these form to be used from a user perspective and from a developer perspective.
The user will probably not want to enter several hundred field on one screen. This means a multi step wizard. Now you will want to put each step into its own sub-interface.
From a dev perspective, you need to think about whether you want/need to reuse parts of these forms for changing or approving the entered data.
With larger interfaces I do not see a point in using the design mode. I typically do a draft in design mode and as I add logic, switch to expression mode and stay there.
Yeah can you post your full expression on Community? I wouldn't expect that just SAIL components would cause this - what other logic do you have in your interface?
Also is this only in design view? What happens if you actually use this interface in a process / report - is it faster there?
Thank you for your reply. We try to use a given component for multiple text fields or whatnot, where possible. For instance - we will use a 'columns layout' and then within that we will put multiple text boxes both horizontally and vertically.
We also are not putting hundreds of fields on a given 'screen,' or rather we are trying to avoid doing it. We are in the mortgage industry, and so there is inherently a ton of fields needing information. We have been going into the "Patterns" tab and using things like "Navigation." Although we are using multiple 'screens' within the 'Navigation' pattern, we are putting all the fields/components within the same interface.
Sure, as stated in another comment, we are in the mortgage industry and for this specific interface I don't mind sharing the code. This interface is not as bad performing as the interface that sparked me to post this, but this interface isn't even half done and performance is already suffering in design/expression modes. I anticipate that its performance will be equally bad with initial interface causing me to post this thread once complete. Inserting code is getting an error, so see attached text file.
For what it's worth, I copied that code into an interface for me and wasn't seeing 10 second load times - I mostly saw ~1-2 seconds in design view. In there's a lot of ways you could vastly simplify your code that might also help. For instance, you're repeating this exact expression around 20 times:
label: "Fee Description",
label: "Adjustment Type",
placeholder: "--- Select a Value ---",
showWhen: local!Section_K_AddRows >= 2
Can you instead save this as its own interface and just call it where you need it? Or even better, could you use a grid to display the data instead?
© 2021 Appian. All rights reserved.