As we develop more and more perspective systems and build out our display libraries I am seeing a performance concern I wanted to ask about. We are utilizing many multi level embedded views for say a motor that is part of a machine that is part of a system. I have noticed that depending on the level of embedded view nesting, sometimes parameters and/or bindings in the lowest levels aren’t always correct. I am convinced it is caused by the rendering/binding/parameter passing update race that occurs when a view is displayed. Is this something others have noticed, it seems this has improved with version updates to ignition but still causes concern. Any info and or thoughts are welcome.
That issue sounds similar to a bug (confirmed by IA) that I have an open support ticket on. Bindings on embedded views are not being evaluated on page initialization. It seems specific to binded parameters that are complex data types (dictionary and lists).
The issue becomes more apparent with a larger quantity of embedded views on a page. The amount of levels the views were embedded did not make a difference.
I don't know if it will help in your case, but I was running into a similar issue and I think what solved it for me was changing the loading order to "after-parent." It could be a bit slower to load, but it should ensure that the parent's parameters are present before the next view starts loading. It's something you could try at least.
I appear to have this issue to. I have very strange behavior occuring when I have multiple embedded viewed being rendered as part of a view. I am really struggling to get to the bottom of this.
Its a Perspective View (like yourself) with a single embedded view. that single embedded view leverages multiple flex repeaters of other views. The flex repeaters are showing the correct parameters but then revert back to some fixed value, every time.
If you’re in a position to do some testing, try out our Periscope module:
It adds both Embedded View + and Flex Repeater + components, that do all their parameter mapping on the gateway side, preemptively start their views, and expose a key property to allow for correct instance insertion/deletion.
It’s not going to be a silver bullet for any misconfiguration that you might currently have, but in our experience it solves a lot of the current weirdness with deeply nested embedded views.