Question

I understand that when creating a custom component, it’s normally best practice to defer any property changes to it by using setters/getters, setting a “dirty” flag, calling invalidateProperties(), and then letting commitProperties() handle the actual changes.

But in the case where properties only affect Spark components, wouldn’t this be redundant since Spark components already defer their property changes?

For instance, say I have a custom UIComponent that contains a Spark Button and I want to expose a buttonLabel property for it that changes the label of the button:

private var _buttonLabel:String;
private var myBtn:Button;
private var _buttonLabelChanged:Boolean = false;
function set buttonLabel(lbl:String){
   _buttonLabel = lbl;
   _buttonLabelChanged = true;
   invalidateProperties();
}

So then setting the buttonLabel property will then eventually trigger:

override protected function commitProperties(){
    if(_buttonLabelChanged){
          myBtn.label = _buttonLabel;
         _buttonLabelChanged = false;
    }
}

But the setter for “label” in the Spark Button class is already using an invalidation process which makes the above code pointless, yes? Or am I missing something?

Answer 1

But in the case where properties only affect Spark components,
wouldn’t this be redundant since Spark components already defer their
property changes?

I don’t believe this is a true statement. Spark Components do not defer their property changes any differently than MX Components.

But the setter for “label” in the Spark Button class is already using
an invalidation process which makes the above code pointless, yes? Or
am I missing something?

Yes, you are missing the fact that every spark component has it’s own invalidation cycle. this is no different from MX Components in which one MX Component contains another.

I’m not clear, but you appear to be looking at two identical things (MX Invalidation and Spark invalidation) and saying they are different.