I'm wondering if binding the name of a perspective component to another property is a bad idea. I tend to place a bunch of different embedded views in parts of my project, which take in a label parameter. Eg, the following status indicator:
Is there any downside to binding the name of the embedded view to be the same as the label (the label remains static)? It means that as I copy/paste the embedded views, I only need to change the label property, as opposed to also manually giving them a name.
Obviously, this assumes that components will have unique labels, but in my case this is true.
My thoughts are that every binding has a cost, so the more "development" bindings you have, the less the scalability you have in the long term. As much as I want to make my dev easy and smart, I fight the urge to do things like you mention to minimise this development impact on the running system
Yes, it is a really bad idea. You don't know what kinds of things depend on it under the hood, or might in the future. (This is a real problem in Vision, too.) Don't do it.
Instead, use the name as the source of a binding, if necessary.
Also agree, it all breaks the moment you need two of the same labels in a view.
And when I say breaks, it really messed up and I had to wipe the gateway because Ignition tries to rename the item back to the copy of item name every time it opens the component, then it runs the binding and renames it back to the conflicting name, which forces ignition to reopen the component...
It's not that many. There's maybe 30 embedded views acting as labels on a map I'm making. It's not enough work to justify editing the JSON. I can just spend the 2 min to set the names manually, lol.
I think Nick was talking about scripting the JSON files to generate the components with the custom names from the start, instead of changing them inside Ignition.
