# Binding to Custom Component Methods

**URL:** <https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245>\
**Category:** Ignition\
**Tags:** scripting\
**Created:** [August 14, 2018, 4:58pm UTC](https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245 "2018-08-14T16:58:24Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 16, 2020, 11:29am UTC](https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245/17 "2020-04-16T11:29:23Z")

</div>

See also more recent rant about tag() expression performance implications:

> [@Nesting Not Allowed while using Properties in a Template to turn on a Light](http://forum.inductiveautomation.com/t/nesting-not-allowed-while-using-properties-in-a-template-to-turn-on-a-light/33609/16):
>
> 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…

---

_[View the full topic](https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245)._