Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tskimmett opened this issue Nov 29, 2022 · 0 comments

Comments

@tskimmett
Copy link
Contributor

tskimmett commented Nov 29, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant