We pass parameters three to six views deep and get intermittent issues with the quality overlay red box of death due to a parameter not updating before the screen is finished load. I have been fixing this by using a now(1000) expression binding to update the parameters afterwards with a script. I would take any suggestions on if there is a better way to do this.
Hi, I assume you're talking about vision here?
I usually tick "overlay opt-out" on all my bidings so it does not ever display the red box.
That also means if your binding has a bad value, the red square will not be displayed. That has always been fine with me as I don't like the red square and I usually make sure that by default the template (vision) or view (perspective) loads with a clean look even with no data.
No perspective. Not trying to hide the overlay at this point, just trying to get the parameters to pass consistently to the final imbedded template.
Is your embedded view loading order parameter set to "after-parent" to load the embedded view after it loads the parent view?
Keep in mind that in perspective it is better to avoid having too many layers of embedded views as it can impact the page loading time and responsiveness especially if you transfer a large amount of data through the layers.
You can also try setting your view to "blocking" loading mode to see if that help. That means the page will not render until it has rendered everything in it. I never had to use it myself but check if that helps.
1 Like
Please don't call your views "templates", then. Or consistently tag your topics with "Perspective". Vision has Windows and Templates. Perspective has Pages and Views.
Sorry, we have a folder called 'Templates' with all the reusable views. I was looking at that when asking the initial question.
I thought I saw one of the Inductive employees mention one time that embedded views should only ever be 2-3 levels deep otherwise you could have issues. I don't remember what topic this was on otherwise I'd link it, but I recall seeing something like that once.
Might check out this thread as a whole as this link has some tips on improving performance in particular regarding embedded views:
2 Likes
Yes we are blocking and after-parent but still intermittent results. Typically if we reload the page it will finally fill out the data.
Have you tried blocking and with parent? Or not blocking and with parent just to try different combinations to see if one works better in your case? I've never had the issue of the data not loading at all or partially loading, even when we made the mistake of having too many layers of embedded views. It would load slowly with ugly rendering of temporary unknow values but it always loaded the values eventually without having to refresh the page.
What you could do as well on your bindings is to use an expression binding or expression transform to handle temporary bad or unexpected values with a try or isGood and a default value you want to display while loading.
Are you using any tag() expression functions in your UI bindings?
No but the views I am dealing with are 4 and 5 layers deep.
We've hit this issue (or something related) a few times. Despite IA Support saying that is is triggered by a 'race condition' I don't know if they've ever confirmed that it's a bug (even though I'd consider any race condition to be a bug).
One thing I've found to potentially help is making sure 'persistent' is disabled on any of the properties which have the problematic bindings. It looks like someone else on the forum has a similar suggestion: Flex Repeater instances sometimes initialize null values (embedded view) - #14 by rpavlicek
Persistent didn't matter either way but thanks for the suggestion. So far the only thing I have found to work was changing binding to an expression and using now(1000) to continually update the parameter to what was passed after the view opened. I only have to do this once I hit the third layer and it doesn't happen every time but is inconsistent in pulling in the parameters.
Would it be better to just restructure things to not use so many layers? I realize you're probably trying to create/use re-usable components, but if things get over-standardized and the expense is poor performance, is it worth it?
Unfortunately, I walked into an already developed project. I agree it would be better to restructure but I am busy with other development items on my list. Maybe at a later date. I have a lot of ideas.
I've come across this kind of issue when there are bindings that are reliant on the result of other bindings, especially bindings that fire when the view loads. You can't control the order of those initial bindings firing. There are lots of variations of this pattern as I'm sure you can imagine.
It seems like a silly mistake, but I've seen this multiple times and it results in very inconsistent results when loading a view. If the results of these bindings are used as parameters to nested views that also exhibit this pattern, then all bets are off.
a timer binding where do you use this?
You can actually control the order of bindings based on one initial source. I use change scripts on the parameter or custom props when I have to control order or operations.