Suppose I have a view that takes a parameter from the page path. The view contains several other nested embeeded views to which parameters are still passed from page. These views contain clickable components.
The problem is as follows - when the operator clicks a component right after the page is launched, it is launched with an old parameter (one that was set by default in the designer) which causes it to be launched incorrectly. I suspect this has to do with the parameter being passed between views too late.
How can this be prevented. So far, the only thing I can think of is hiding the component after launch for a period of time or are there better ways?
Sounds like you have intense calculations and/or DB queries and/or other network requests between parameters set at the page's view and parameters delivered to nested views. If you cannot simplify those operations, your inner views will need "sanity checks" to prevent operation until proper data arrives. Disabling components (not changing visibility) is the most operator-friendly way to do this.
Consider also setting properties that suffer from stale designer values to non-persistent, so they will be null at runtime until their binding evaluates. Use
isNull() expression functions to get "safe" behavior downstream.
It is a simple parameter that is passed "in depth" several times there is nothing complicated however the delay is visible. So I understand that it is necessary to somehow validate the correctness of the passed parameter and to disable the component for the waiting time.
Consider not doing this anyways. Deeply nested views create a huge performance bottleneck in Perspective.
This allows you to create fewer screens and use existing ones but it actually slows down the interface.
Thanks for your opinion!
I've used CSS to create a "fast" and "slow" load fade-in effect. Fast has a shorter fade-in time and slow has a longer fade-in time. Apply it to the appropriate view. Data will load in as it fades in.