Bindable vs dirty flag in commitProperties - actionscript-3

Question

What is the best way to bind a property to a component in Flex?
Say I have to update the text field of a TextArea. We can do it in two ways:
1.
AS3:
[Bindable]
private var myText:String;
//setters getters
MXML:
<mx:TextArea id="description" text="{myText}"/>
2.
AS3
private var myText:String;
private var myTextChanged:Boolean;
public set myText(pText: String): void
{
if (myText != pText)
{
myText = pText;
myTextChanged = true;
invalidateProperties();
}}
override protected function commitProperties():void
{
//other code
if (myTextChanged)
{
description.text = myText;
myTextChanged = false;
}
MXML
<mx:TextArea id="description"/>
AFAIK, the second way is clean, but has lot of code and extra variables (dirty flag). But I am not sure about the first way as I see Bindable tag is not preferred for performance implications.
Anyone with any thoughts?
Thanks in advance.

Answer 1

In your particular lightweight example the answer is… there is no difference. But that's only because I know the TextInput.text property uses the second method and commitProperties.
If you set the TextInput.text property 1000 times it will only draw once.
Not all code functions this way even though the framework prescribes it… it does not enforce it and sometimes when you're setting a property with bindings it can kick off many other methods behind the simple property set and does not use commitProperties and invalidation to batch the updates.
Also the code that the compiler generates for binding is not efficient. If you have a mobile project I would avoid bindings.
Also you're not binding to an object and a property (i.e. myObject.myText) but a simple string. This is where binding is useful. You're example falls down in this case and would require dispatching a custom event from myObject when the myText property changes.
Binding is always inefficient in that the code that's generated is verbose and is not as simple as a callback or using invalidation. That being said it's almost always acceptable from a performance standpoint to use bindings in place of writing a bunch of code to do exactly the same thing.
Another gotcha is that bindings are also static in nature. In other words… they exist in the global scope and cause user interface elements to stick around and not be garbage collected. A good example of this is binding to the data property in an itemRenderer that get's recycled. It is always a bad idea to use data binding in an item renderer because of this. You should override the set data(v:Object):void and/or use commitProperties.
For the record… I like binding… I use it all the time. You just have to understand that:
There is a performance hit.
It doesn't obey Flex's invalidation model (i.e. commitProperties)
It occurs in the global scope and can cause objects to hang around.
If you want to have a look at the code the compiler generates you can add a compiler option:
-keep-generated-actionscript=true