Some computed methods need non-contextual dependencies, it's not DRY to always list them

[sjmiles]

Consider a translation scheme:

{{translate(translator, 'Hello World')}}

translate: function(translator, text, params) {
  return translator(text, params);
}

The design is that the 'translator` engine is injected by some means (simple property set, e.g.), therefore we must depend on 'translator' to trigger the relevant binding updates. Having to include this static name in every translate binding is a hassle.

One possibility is to add a way to register static dependencies for a computation.

{{translate('Hello World')}}

depends: {
  translate: 'translator'
},
translate: function(text, params) {
  return this.translator(text, params);
}

Something like that.

[robdodson]

bonus points if this plays nice with behaviors

[TimvdLippe]

I submitted an implementation in #3302 .

The implementation is a bit different that the proposal. I discussed this with @sjmiles and he agreed it was "a superior solution".

The example in the docs is:

<dom-module id="x-computed-with-dependency">
  <template>
    <span>{{methodName('literal')}}</span>
  </template>
  <script>
   Polymer({
     is: 'element-with-dependency',

     properties: {
       property1: {...},
       property2: {...}
     },

     dependencies: {
       methodName: ['property1', 'property2']
     },

     methodName: function(property1, property2, literal) {}
   });
 </script>
</dom-module>

I have not tested behavior support, but I think that could be implemented fairly easily. Could you elaborate on the specifications for behavior support? E.g. What should happen when behavior and child both declare the same or different dependencies?

[robdodson]

Thanks for looking into this @TimvdLippe!

Could you elaborate on the specifications for behavior support? E.g. What should happen when behavior and child both declare the same or different dependencies?

For my use case I'd want the implementation for methodName and dependencies to both be part of the behavior that gets mixed in to the element.

As for parent and child declaring same or different dependencies, I haven't thought about that much... Maybe parent just overrides the required dependencies of child?

[sjmiles]

@samccone: unless I'm missing something, your pattern can't update the text in the <p> when the 'translate' method changes. This is a critical bit provide by the 'dependencies' solution.

[sjmiles]

@TimvdLippe: to follow current behavior rules, the dependencies objects should be (effectively) combined, everything else follows the standard inheritance model (i.e. any method implementations are 'last one wins', where 'last' means left-to-right in behavior arrays and the user's prototype at the end [the very last]). Conflicts in dependencies should also be handled as 'last one wins'.

[samccone]

@sjmiles yep your right nm

[TimvdLippe]

@sjmiles @robdodson Behavior support should now be added to the dependencies maps. Please check out this test

[robdodson]

Cool so it looks like this covers this aspect:

Conflicts in dependencies should also be handled as 'last one wins'.

Are you also thinking of adding merged depenencies?

[TimvdLippe]

@robdodson Merging of dependencies was already possible, but I forgot to add an explicit check for it. I have updated the test to show merging of dependencies works correctly.

[robdodson]

cool! I'll defer to @sjmiles for approval

[sjmiles]

LGTM, will run it by @sorvell and/or @kevinpschaaf for extra care.

And ... nice work @TimvdLippe!

[kaste]

I'm a bit confused why this is called dependencies when what it does is: Iff this method is used as a view helper function, we inject these properties automatically for you. Or: when used as a view helper, you work with a partial/bound function. Within your normal JS there is nothing special about this method.

[TimvdLippe]

@kaste The new behavior of this feature is that annotated computed functions can be updated whenever one of the global arguments is changed. In my eyes, inject means the notion of one-time injection of a dependency, whereas this feature guarantees continuous updates. Therefore I would still call it dependencies rather than injectees or alike. However, if the behavior could be better described we can of course change it.

[kaste]

Take #3358 as a rough concept. I really have no idea if it fulfills all and every requirement. On the other side it's in the same ad-hoc style as the rest of the Polymer source code.

Following example:

<dom-module id="x-bind-computed-property">
  <template>
    <div id="check">[[translate('Hello World.')]]</div>
  </template>
  <script>
    Polymer({
      is: 'x-bind-computed-property',
      properties: {
        translate: {
          type: Function,
          computed: '_computeTranslateFn(translator)'
        },
        translator: {
          type: Function,
          value: function() {
            return function(message) {
              return 'translated: ' + message;
            }
          }
        },
      },

      _computeTranslateFn: function(translator) {
        return function(message) {
          return translator(message);
        }
      },

    });
  </script>
</dom-module>

As you can see translate is a bound function in the sense that it is a property controlled by Polymer. In the example the property is a computed, but this is not required. You could use a complex observer that assigns a new function to translateas well.

As you can see 2: No further configuration is necessary. And although functions which return functions is always a bit meta and an advanced topic, I think any programmer can grab the concept without reading the documentation. I actually tried this before (I wanted to implement the filter function for a dom-repeat in this way), but it wasn't supported (which wasn't documented by the way). So this approach more likely fills a gap in Polymer.

[kevinpschaaf]

We had a bunch of discussion on the Polymer team about the pros/cons of the alternate approaches by @TimvdLippe (#3302) and @kaste (#3358). The upshot is that people actually found it strange after thinking about it that observers/computing functions didn't have themselves as an implicit dependency, which is indeed an alternate way to solve the dependency currying problem for the translate use case as @kaste's PR showed. So I think I'll re-open #3358 and make a couple more suggestions there for improvements, and see if we can reach agreement on that approach.

[dfreedm]

Fixed with #3358

[kevinpschaaf]

For posterity, here's an example using the technique we merged (dynamic computing functions) to implement late-bound string translation via a behavior that results in a pretty pleasant end-user experience: http://jsbin.com/lajuci/edit?html,output