Vartan Simonian
An interesting discussion popped up on Slack regarding the currently supported syntax for accessing object properties.
Currently, Polymer 1.0 supports object.key and array.index, a far cry from the variety of syntactical options that 0.5’s expressions supported, but very much worth the compromise considering the significant blow that complex expression parsing deals to performance.
However, take the use case of accessing an object’s properties by key when the selected key is determined a variable. With Polymer 1.0’s current support, object.key is not an option. object[key], on the other hand, is not supported. This leads to:
<my-element some-prop="[[getKey(obj, key)]]"></my-element>
<script>
...
getKey: function(obj, key) {
return obj[key];
}
This seems to be more effort than it is worth for a rather simple and commonplace operation. Additionally, at a first glance, object[key] doesn’t seem to be a very complex syntax to add support for, and the aforementioned implementation seems a tad more expensive in performance, or at least roughly just as expensive.
However, these are all observations made without any intricate understanding of the innards of the binding mechanism; I’m no expert on this topic, I will admit. So, I thought it’d be a good idea to ask:
- What is the performance cost of supporting
object[key]? - What is greater - the performance, or the loss of convenience and terseness?
Vartan Simonian
In addition to the concerns I’ve already outlined, another was brought up by a user on StackOverflow that I hadn’t even thought of - two-way data binding.
Using a computed property to bypass the lack of support for obj[key] means that the binding will be only one-way. This is another important factor to consider.
Vartan Simonian
I’ve written up a guide to accomplishing two-way data-binding without bracket-notation with a sample usage case as an answer to a related question on Stack Overflow.
It seems very (unnecessarily?) complex compared to binding to obj[key] - but of course, I am not yet aware of the performance implications by both methods, so I cannot call any judgement.
