Refactor suggestions about @Input and implementing a custom decorator

[lazarljubenovic]

The code is currently using inputs array of strings on component metadata to tell Angular that properties with these names are to be considered inputs. This way of listing such properties is currently considered bad practice according to official Angular styleguide. It makes sense: maintaining is difficult because it's scattered around, and let's not even begin on typos and refactoring.

So my first suggestion is moving away from inputs and using @Input() instead.

In a similar fashion, we're maintaining an array of strings _mapOptionsAttributes in order to iterate over them more easily. This can be solved with a custom decorator; here's a proposed simple implementation.

function MapOptionAttribute() {
  return function (target: SebmGoogleMap, key: string) {
    if (!target.constructor._mapOptionsAttributes) {
      target.constructor._mapOptionsAttributes = [];
    }
    target.constructor._mapOptionsAttributes.push(key);
  }
}

And example usage:

class SebmGoogleMap {
   @Input()
   @MapOptionAttribute()
   public longitude: number;

   // We basically need this just for typing information in here.
   // The actual value is assigned through the decorator.
   private static _mapOptionsAttributes: string[];
}

The accompanying JS bin in action is also available.

How does it seem? Any suggestions? @SebastianM, if you like the idea, I could work out a PR.

[lazarljubenovic]

It was mentioned in #863 (comment) that a reason for not doing this is being unable to generate docs. There doesn't seem to be a proper document generation tool for Angular (yet). However, ng-bootstrap has a custom script for generating docs which is probably worth checking out.

[stale]

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.