Weird things Salesforce Lightning does #1

I have been working on Lightning component development a lot and have always discovered some new things Lightning does without giving any documentation. It can be weird, surprising, concerning and pleasuring at the same time(mostly concerning and creating unexpected issues).
This post is titled with #1 as I am hoping to have more such discoveries and planning to post them as I come across them, maybe one or more things in each post.

So in this post, I am going to share two such things that I discovered recently while working with Lightning Components. Here it goes…

#1 Surprising behavior of Lightning Framework

We developed a lightning component for community having a form with lots of fields and custom validations. One of the custom validation was — if a field is required, it should have a value input by user. If the required field is not populated, then highlight the field with a red border. In our case, due to some reason we used custom metadata type to store properties related to all the input fields on the form. So we had a string field to store field API name and a checkbox field to store whether the field is required or not along with some more properties about the field.
In the JavaScript controller, we used records from this custom metadata type to lookup and check whether a field is required or not. This was done by iterating over each custom metadata type record and checking each field value in the record defined using a component attribute.
Testing went well and everything worked as expected. :)
This code was then deployed to another sandbox for integration with other code base.
And guess what? This same component (not much surprisingly) stopped working. One of the fields on the form was showing a red border around it even though the value was populated!

So what was the cause for this surprising behavior?
After deployment, API name of one of the fields referenced in the component markup was changed after deployment in this integration sandbox. Salesforce actually changed the field reference in my code to this changed API name AUTOMATICALLY! Can you believe that? I did not believe this as I did not recall reading something like this anywhere in the documentation. We all also know that this doesn’t happen if the field is referenced in Apex or Visualforce.
To validate this behavior, I tried to replicate this and it actually happened!

Component markup BEFORE changing the field API name:

CustomField__c was then changed to CustomField_Changed__c

Component markup AFTER changing the field API name:

One thing to note here is — this won’t happen if the attribute type is NOT a concrete sObject.

Conclusion:
This can be really very useful if we have no references to the field in the JavaScript code for the component because above happens only for the component markup. I don’t think we can expect this to happen in JavaScript controller and helper of the component bundle as JavaScript is a loosely typed language.
I could have not possibly discovered this if we did not have those custom validations for checking a required field.

But as they say — everything happens for a reason! :)

#2 Unknown syntax for component.set() and component.get() methods which worked!!!

Recently, I was going through a Lightning component code and found a line of code(referred to as LoC hereafter) which I thought will never work based on the Salesforce documentation that I have read.
This LoC mentioned above was simply setting a value for a component attribute.

As per this documentation, the syntax for setting and getting attribute is as below:

To get the value of a component’s label attribute:

var label = cmp.get("v.label");

To set the value of a component’s label attribute:

cmp.set("v.label", "This is a label")

The LoC which struck me as a surprise was something like this:

Notice what’s different here than the documented syntax?
The first parameter in component.set() has the expression syntax which we use in the markup to specify the attribute name.
“This MUST NOT work!” was my first reaction, so I went ahead and asked the developer who wrote the code if it works. It was a “Yes.”.

As in the first case, I validated this by writing the same code for component.set() as well as component.get() methods. It worked without any errors and here we discovered another undocumented feature that Lightning has!

Conclusion:
Even if this works, it is not documented and so should not be used as this may change anytime and all you will have is a lot of non-working Lightning components.

Let me know your thoughts around this. Also share such weird things that you have observed while developing Lightning Components. I hope you all liked what I have shared here!

Keep Coding!