Skip to content

Customizing property behavior for sub type can alter behavior of property for base type or sibling types #105

Open
@tskimmett

Description

@tskimmett

When model options declare a type which $extends another type, it is possible to specify options for a property which already exists on the base type. A good use case for this is to define a property on a base type, then configure it to be calculated for a sub type:

{
   Device: {
      HasPower: Boolean
   },
   Television: {
      $extends: 'Device',
      IsPluggedIn: boolean,
      HasPower: {
         get: {
            dependsOn: 'IsPluggedIn',
            function() {
               return this.IsPluggedIn;
            }
         }
      }
   },
   CellPhone: {
      $extends: 'Device',
      BatteryLevel: Number,
      HasPower: {
         get: {
            dependsOn: 'BatteryLevel',
            function() {
               return this.BatteryLevel > 0;
            }
         }
      }
   }
}

However, in this example, the configuration of the sub types' HasPower property to be calculated inadvertently configures the base type's property to be considered calculated. This pollution of the property, which is shared for all three types in the above scenario, can lead to unexpected behavior. In this example, the property won't be properly initialized for an instance of Device since the framework thinks it is calculated, and should not be initialized to the default value for Boolean properties (false).

The root of this problem is the storage of certain, type-specific, metadata on the Property instance itself, such as whether or not the property isCalculated. Ideally, a property can be configured such that it has variable behavior for sub types, even though the property is declared on the base type. Behavior would include (but not limited to) things like if/how the property is calculated, whether or not it has special initialization logic, or whether or not that property is required to be filled out for the sub type.

Ideally, this problem would be solved by storing this metadata on a secondary object that is tied to the type for which the metadata was declared, instead of on the property itself.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions