Why shouldn't I use tag() in an expression

[Pat_Cunningham]

Why shouldn't I use tag() in an expression

[Felipe_CRM]

Help with Tag Expression

Expression bindings are synchronous. They must return a value when executed. The tag() expression function stalls when first called, waiting for a reply to its subscription request. If you scatter tag() expression functions through a bunch of bindings in a commonly-used view, you will have stalls on those views that are the sum of all the stalls in the bindings. Tag bindings don't stall. They simply don't produce any property assignment at all until the subscription answers, and only produc…

Indirect tag in an expression binding?

There are many other posts like this

Just to get you started down the rabbit hole.

EDIT: Another good reason:

Nesting Not Allowed while using Properties in a Template to turn on a Light

Yes, there is. If the items that comprise your tagpath are updated, even if yielding the same result path, the entire expression containing the tag() function will have to execute. With indirect binding, this doesn't happen. The strings themselves have to be reconstructed every time, even if not changing, slowing down the final expression execution. There are a few cases with computed gateway tags where the tag() expression is the only good way to do indirection, and the dynamic stuff above…

[Pat_Cunningham]

I thought I read it somewhere but I couldn't find it. Thank you very much.

Ugh Configuring Indirect Tag Binding takes forever. Is there anyway to create them without going through the interface

[pturmel]

I tend to use "Copy Binding" then "Paste Binding" then edit.

If your indirect binding always looks like:

{1}/SomeName

or

{1}/SomeName.SomeProperty

with {1} always pointing at {view.params.tagpath}, then making many of these is fairly easy.

[Pat_Cunningham]

So if tag() is so much trouble why is it even available as an option?

[pturmel]

It is the only way to do indirection within expression tags, and the expression function registration system doesn't make a distinction about where the function could be used.

I would be in favor of tag() throwing a config error if used anywhere else.

A long, long time ago (in a galaxy far, far away) indirect tag bindings didn't exist, and tag() was the only method. It limps along for backwards compatibility reasons.

[Pat_Cunningham]

I would also be in favor of an error. I used it everywhere...Damnit

[msteele]

Or at least it could be helpful to have some more warnings/caveats in the docs. I used to use tag() everywhere all the time until @pturmel set me straight.
For example, add more warnings here:

tag | Ignition User Manual

[Transistor]

Don't tell us! Tell docs@inductiveautomation.com.