CODEWITHSUNDEEP
javascriptpolymer-1.0
Dimitrios Mistriotis
Dimitrios Mistriotis

Reputation: 2788

v1.0 polymer element access attribute from element

The aim originally was to supply an configurable image location for a polymer element. It seems that I have understood something wrong and not doing it the "polymer way". The question is about how this should be accomplished and if the approach is the right one.

From the calling page:

<mycustom-element imagelocation="/correct/path/to/images"></mycustom-element>

And the element:

<link rel="import" href="proper/path/to/iron-image/iron-image.html">

<dom-module id="mycustom-element">
  <style>
    :host {
      display: block;
    }
  </style>
  <template>
    <iron-flex-layout class="layout horizontal wrap top-level-menu">
        <iron-image src="{{getLocation('image_file_name.png')}}"></iron-image>
    </iron-flex-layout>
  </template>
</dom-module>
<script>
  (function () {
    Polymer({
      is: 'mycustom-element',
      properties: {
        imagelocation: {
          type: String,
          value: "/wrong/path/to/images"
        }
      },
      ready: function() {
        console.info('RD', this.imagelocation);
      },
      getLocation: function(imageFilename) {
        console.info('GLOC', this.imagelocation);
        console.info('GLOC_PROP', this.properties.imagelocation.value);
        return this.imagelocation + '/' + imageFilename.trim();
      }
    });
  })();
</script>

The problem that I have is that when viewed on the browser, the value of "this.imagelocation" is the default one, not the one provided from calling page.

The output in the console is the following:

GLOC undefined
GLOC_prop /wrong/path/to/images
RD /correct/path/to/images

Was wandering what is wrong? Does it have to do with element's life cycle? Can it the function call be delayed?

Upvotes: 0

Views: 240

Answers (2)

zerodevx
zerodevx

Reputation: 1591

Actually you kind of answered your own question. FWIW, the behaviour in your original code is expected - and you are correct to say that it is due to Polymer's life cycle behaviour. When you bind

<iron-image src="{{getLocation('image_file_name.png')}}"></iron-image>

to a computed function, the node gets stamped when all properties in that function are ready. In the above case, you actually passed in a fixed variable, which is always "ready", so some time between <mycustom-element>'s created and ready callback, getLocation() is already called, which might be before or after the imagelocation published property's default value is set - default values for Polymer properties are also set somewhere between created and ready - resulting in a race condition.

In your specific situation, the "polymer-way" will be to declare <iron-image> like this

<iron-image src="{{getLocation(imagelocation, 'image_file_name.png')}}"></iron-image>

Your getLocation() computed function might look something like this

getLocation: function (l, f) {
  return (l + "/" + f.trim());
}

Done this way, because imagelocation is a parameter of your computed function, you can guarantee that getLocation() is called only after the imagelocation published property's default value is correctly set.

Upvotes: 1

Dimitrios Mistriotis
Dimitrios Mistriotis

Reputation: 2788

It took me some time, writing what happens here for benefit of others:

When "getLocation" is called, it is called from the context of the "iron-image". It seems that iron image inherits the parent element but because no attribute is supplied it keeps the original value, "/wrong" and does not get updated to the correct one. The supplied value does not propagate.

One workaround is to call "getLocation('image_file_name.png', imagelocation)" which is called from the template's context hence it has the updated therefore correct value.

If there is another more appropriate approach, please suggest it.

Upvotes: 0

Related Questions