Occasionally when I open a view in the designer all the embedded views with bidirectional tag bindings will be reset to the default values (0 in my case). The only thing I've been able to find about this issue is a change log from Oct 2021 saying that this was a problem that was happening and it was fixed.
I am posting partly to bring up that this is still a problem, but I am also wondering if anyone else has experienced this and might've found a temporary workaround.
Here is an example of one place in my project I experienced this problem. That is a flex container where each line (besides the label) is an instance of the same embedded view, and all the values were reset to zero when I opened the view in the designer.
In the view definition of the embedded view instances, is the tag binding on an input/output parameter (as opposed to the component in the view)?
If so, 8.1.22 includes some fixes that may address the behavior you're seeing here. It was just released - if that didn't fix it we would recommend you contact support. (If you can't upgrade soon, one potential setting that may reduce the odds of this occurring would be the loading > order prop on the Embedded View component: changing it to "with-parent".)
Changing the loading order to with-parent seems to fix it, but I am going to try updating to 8.1.22 so I don't have to change that everywhere on my project if possible.
Sorry for the late response, I am not currently able to work on this project every day. I updated to 8.1.22 and am still having the issue. I am going to switch everything to with-parent for now, but it is a relatively large project so that will be pretty inconvenient. I would definitely appreciate it if someone could look into this issue and try to resolve it going forward.
edit: I am working on this project remotely through a VPN, so it's possible the issue is latency related.
Bringing back this old topic...
Currently in version 8.1.38. We are having this problem.
In our case we have about 3 Embbeded Views all set to "load-after-parent".
In this case the binding to the tag is set in the main view and the value gets passed from embbeded view to embbeded view arriving at the toggle switch. All params and bindings are set to bidirectional.
Sometimes when we enter the view the value is set to the default of the embedded view, but the tag doesn't change at all. Looks like is only visual.
We have checked this.
It was caussed by a "Refresh" action we had on the "onStartUp" action on component.
The page got loaded twice and that made the embedded view not load correctly the data.
This was curious because the tags wouldn't change the data, only affected visually to the page.
In my experience, this can happen when there are network issues (latency, hiccups, etc) between the client and the gateway.
My EmeddedView+ component does not have this same issue.
So once again, I'm going to keep plugging my EmbeddedView+ component until someone from IA acknowledges that things could be improved.
Specifically, it’s because I initialize the view when the delegate starts, which is usually before the client requests it. When the client does request the view, it’s already loaded, running, and bindings have been evaluated.
In this example video, my component is on the left and IA’s version is on the right. You’re seeing 5 layers of nested views with near instant binding propagation + preloading.
Wow, that's a great comparison. Well, not great that the ia component has this issue.. But good argument supporting yours. OK, I might have to (finally) start using this. Is it an easy plug in replacement for IA's? (from memory it is) but is it literally just changing the component type in the json, if I wanted to do it in bulk?
Does this solve the 2-3 nest limit with IA's embedded views where any deeper has the issue of params not being passed through randomly if you have a moderate to largeish number of embedded views on the page?
It’s not quite a drop in replacement, I use viewPath and viewParams instead of path and params.
The FlexRepeater+ has more differences too, it allows you specify a unique viewPath for an individual instance (if you want).
I think that issue is related to the OP’s, and should be resolved. Give it a shot and let me know?
I will also say:
I think this about the best you can do improve things as a module developer. I think there’s more room for improvement, but it will have to come from modifications to the core of how Views load.
I’m also not saying my solution is the “best”. But at least I’d like some admission from IA that things could be drastically improved.
Freelance developement support to help solve some of these issues?
Sounds great though, I checked these out when you posted them ages ago and they looked , the flex+ with the flexible view path is fantastic, and obviously performance enhancements are a huge win for operators
@bmusson I had some issues with glitching after a page was open for a while. Like if the user tabbed to a different window and came back. I had 5 views, can't remember if it was the repeater or individual embeds but then I'd come back and only 3 of the 5 were working. Is there any kind of known issue or things I should avoid doing? I do really like the module particularly for the initial loading and not flashing the screen red with errors but I haven't tested it enough to actually use it yet. It very well could have been an unrelated issue on my config as it was just a dev test I threw together one day.
Also since the object loads the pathing in the gateway, is there any issues with pathing updating later after initial load? I'm not entirely clear how that works in this implementation. Like if I have a embedded dashboard for a instrument and then I click a different instrument and want to change the viewpath binding on dashboard to point to a different layout.
Do you remember what version you were running?
I believe this was fixed in 0.10.0.
I don't exactly understand what you're describing, are you asking if you can change the viewPath once the page is loaded? If so, the answer is an easy yes.
it wasn't great!
, the flex+ with the flexible view path is fantastic, and obviously performance enhancements are a huge win for operators