Polymer: How to override computed property?

Created on 5 Dec 2017  路  3Comments  路  Source: Polymer/polymer

Description

How to override computed property?
For instance, how to add a dependency to the compute function, or replace the compute function with another, from the child class.

Live Demo

Here's a snippet where the parent class A computes the result property to be equal to the value property, while its child class B would recompute the result property to be equal to value + value2.
But the override doesn't work...
http://jsbin.com/hoqeyucize/1/edit?html,js,output

Here's the stackoverflow.

Expected Results

The computed property to be computed as the child class redefines the compute function.

Actual Results

The computed property is computed as the parent class defined the compute function, and cannot be overridable.

Versions

  • Polymer: v2.0.0
  • webcomponents: v1.0.20
2.x bug p2 wontfix

Most helpful comment

The main reason is: polymorphism

My use case is the following:
I have a abstract component Input. This component has 3 main properties:

 {
      /**
        * The current value of the input. It can be anything, string, number, object, array..
        */
      value : {},

      /**
        * Indicates if a value is required in the input to be valid.
        */
      required : {
             type : Boolean,
             value : false,
      }

      /**
        * Indicates if the value property is currently valid.
        */
      valid : {
             type : Boolean,
             computed : "isValid(value, required)"
      }
 }

The valid property is computed by the function isValid. Its default implementation is just:
return !this.required || !!this.value But that's only de default implementation.

Now let's say I've got a child input component, which inherits from the abstract Input component, but its valid property should be computed with a 3rd dependency parameter. For instance, the value of my input is an Array, and the Input would be valid only if the Array has at least one item inside it. Then I will have to add a 3rd dependency to my function isValid(value, requires, value.length) (or even isValid(value, requires, value.splices) if I need to check the content of my array value).
In cases like this one (there are a lot of case where the parent's compute function is just a default implementation), I need to override the compute function, in order to add/remove a dependency parameter, or even compute the property in a completely different way.

Now the reason why to compute another property is not a solution is because we lose polymorphism.
Let's take back our abstract Input component. Now that It has a computed property valid, it's possible to create a another component, like auto-form, which, on call auto-form.validate(), would pass over all Input component it contains in its own DOM, and check their valid properties.
I would like to avoid to run a function validate(), instead of directly read a property, because it will have to call it on each Input component, and the more inputs it has, and the more complex they are, the more latency it will take.

All 3 comments

I'm curious to know why override a computed property?

IMHO, a computed property is computed by an element and this one knows better than me how to compute it (or there is a bug to fix). So, when I extend the element and the child has also a computed property, this one can't has the exact same value. There is something more or something less. Why not just use an other property?

I'm thinking about if I want to use _your-super-element_ that extend _super-element_ and I want use the computed property (that you overwrote) of the parent of _your-super-element_. Should I override it again or directly extend _super-element_ and re-implement the behaviors of yours? Maybe there is a pattern or something that I don't know.

On principle I agree, child should overrides parent definitions.

The main reason is: polymorphism

My use case is the following:
I have a abstract component Input. This component has 3 main properties:

 {
      /**
        * The current value of the input. It can be anything, string, number, object, array..
        */
      value : {},

      /**
        * Indicates if a value is required in the input to be valid.
        */
      required : {
             type : Boolean,
             value : false,
      }

      /**
        * Indicates if the value property is currently valid.
        */
      valid : {
             type : Boolean,
             computed : "isValid(value, required)"
      }
 }

The valid property is computed by the function isValid. Its default implementation is just:
return !this.required || !!this.value But that's only de default implementation.

Now let's say I've got a child input component, which inherits from the abstract Input component, but its valid property should be computed with a 3rd dependency parameter. For instance, the value of my input is an Array, and the Input would be valid only if the Array has at least one item inside it. Then I will have to add a 3rd dependency to my function isValid(value, requires, value.length) (or even isValid(value, requires, value.splices) if I need to check the content of my array value).
In cases like this one (there are a lot of case where the parent's compute function is just a default implementation), I need to override the compute function, in order to add/remove a dependency parameter, or even compute the property in a completely different way.

Now the reason why to compute another property is not a solution is because we lose polymorphism.
Let's take back our abstract Input component. Now that It has a computed property valid, it's possible to create a another component, like auto-form, which, on call auto-form.validate(), would pass over all Input component it contains in its own DOM, and check their valid properties.
I would like to avoid to run a function validate(), instead of directly read a property, because it will have to call it on each Input component, and the more inputs it has, and the more complex they are, the more latency it will take.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings