I have a dynamic setup where a flex repeater loads a device view with embedded value views, but about half of the time (random), the embedded values within will load null. I'm guessing this may be a race condition with the parameters not fully finishing before everything loads?
For more detail, the flex repeater will display device1, device2, etc.., depending on how many devices of the same type it has (some locations may have 1 pump, another with 2 pumps, etc..). The device is a view with a bunch of embedded view components that show values (all of which are from the same single view).
The Flex Repeater simply supplies the base tag path, where the device view has all the embedded 'value' views with params that take the base path and append the last part of the name to finish the indirect binding to get its value to display.
On some further testing, using print statements, it shows that the indirect binding is firing twice that gets the value. I know this is not recommended, but I put a sleep timer of 0.25 seconds in a script transform to return the value, which quickly resolves and displays the correct value.
On the first firing, the initial value is null, but goes to its correct value with a delay. Without the sleep delay, it fires twice with the same incorrect null value and blanks out (since I binded the display prop to false with a null value)
I believe I had to do this elsewhere some time ago, but wondering if there was a way to resolve this without delaying with the non-recommended sleep timer in a script.
Is it happening because your embedded views are rendering before it receive the tag path in your parameter? Have you tried using the "after-parent" loading mode on your flex repeater and / or your embedded view? That might help and avoid the use of a sleep timer, which is not recommended.
View loading settings.* order: Controls when the embedded view loads: alongside the parent view loading (with-parent), or after the parent view finishes loading (after-parent). Default is with-parent.Generally speaking, with-parent is more efficient for the browser, but in some cases can feel slower overall. Alternatively, after-parent is generally less efficient for the browser and can add to the overall load time. However, since it allows the parent view to load first, after-parent may feel quicker since the topmost layer of views get started up sooner. Value is boolean.
Alternatively you could always make your labels not render null values or if you have broken links use "overlay optout" on your bindings.
Does this refer to a bidirectional enabled or having both input/output on the param? I do have input/output for the param with a binding on the value. I can see this being the reason for the potential multiple firings of the binding.
I do this because I am exposing the value at the embedded view params level, because I have another param that binds to it for customizable mappings (case expression at the embedded view level).
I could try configuring the binding to keep it at the root view level. Then at the embedded view, I just input simple text or something.
For the properties that are null to start, but are filled in later, are they being read with scripts? Or are they entirely referenced by property bindings or property references in expression bindings?
Are the embedded value views really that complex that it warrants being their own views and embedding them ?
I try as much as I can to avoid this. I guess it's mostly a matter or personal preferences, but:
I don't need to open multiple views to change things
I don't clutter my project with a thousand little components
It makes a lot of things simpler, like getting values back for example.
It's also often easier to reason about.
More often than not you'll need a slightly different behavior than what you already have, but you'll be tempted to reuse it because it's right there and soooo close, so you'll add parameters, and processing, and soon enough what was once simple is now a complicated mess.
Now, I'm not saying "template views" don't have their place, but I keep them for "complex" things. I guess it's all about defining what "complex" means.
I do have a very dynamic and flexible central view going on. Of what you mentioned, its always on the back of my mind to not get too complex and know when to scale back. Obviously, making use of style classes can handle central styling and such, but I also have properties that look at alarm states and some other things that give it much more power all from one spot.
I'm going to look at other alternatives for the one binding I have that may be triggering all of this.
This sounds fairly similar to an issue I reviewed with support recently (ticket #109329). I was seeing bindings evaluate twice when printing debug statements to the browser. Putting it in basic terms, the null on initialization was somehow taking precedence/occuring 'after' the actual evaluated binding, affecting some downstream bindings.
Eventually, support directed me to modify persistence settings. Truth be told, that project is on the backburner so I haven't been able to test it, but supposedly it fixed the issue in their testing. May want to contact support and see if there's similarity with my case.
Note: my issue was with a specific embedded view, not a flex repeater.
Had the same thing occur. I had bindings on the instances of the flex repeater and found it was being loaded before the parent view was loaded (it would load the default view params first, and then fire off another update when the view params was loaded). So in my print statement it would load the "default" params (in my case was null) first and then the "passed params" even though loading after parent was selected.