Hi all, my customer is complaining about initial rendering of a view. The view is a composition of many different containers, each with a tag binding on the display property: at first loading the UI experience is not the best indeed, because you see all containers for a short while, which then disappear as soon as bindings come into action - some portions show at first the Bad/error overlay, because their display depend upon expressions on tags.
Any suggestion? Is there anything like server side rendering in the roadmap? I think it could be helpful.
We had in our project a loading problem too. We created a loading screen that dissapears when the view is done.
Also, are you using embeded views? We had some views inside views that called templates, and from our experience that REALLY slow the loading progress...
Can you use Expression Language's coalesce | Ignition User Manual function? coalesce({view.params.myOptionalParam}, '') coalesce({view.params.myOptionalParam}, null) coalesce({view.params.myOptionalParam}, 0)
When you add a binding to a property, it automatically makes it non-persistent. After adding your binding on the display prop, try changing it back to persistent.
This should force it to load as whatever you save the view with, that is if you save with display unchecked it should initialize that way on open, then the expression will kick in after that.
A downside to saving persistent values willy nilly is you create headaches when you go to diff changes, not to mention you increase the size of the view which may in itself lead to longer load times. Any changes to those values will appear as changes which are most likely going to be false positives. The better way is as @Transistor suggests, by using coalesce
The problem with coalesce is that it still takes a split second to evaluate, so if you’re using it to determine display, the component will still appear very briefly.
At ICC 2024 one of the presenters suggested using a CSS fade in for slower loading views.
Some things to keep in mind. The more levels of views you embed inside each other the worse performance will be. Try to structure your app to avoid embedding views to more than 3 levels deep (general rule of thumb).
You can see a MANY fold performance improvement by making custom Perspective modules but that is a fairly involved development process involving react. I haven’t personally done it yet but one of my colleagues built a module that reduced CPU load 50 fold (it was crazy). His custom module replaced a multi-layer dynamically populated embedded flex repeater (repeaters inside repeaters).
It’s great that Ignition affords you the opportunity to opt out of the super user friendly tools and sub in highly optimized tools as needed to achieve the performance level your project demands. In the case of the tool my colleague is building it was a real game changer.