Discussion on: My Tooling Wishes for 2020 ✨

[Bram Gotink]

Hi Maël,

A lot of these would indeed be great additions to the ecosystem!
I just wanted to respond to one item: the decorators in clipanion.

At work we've enountered a similar problem. Allow me to quickly paint the situation: Angular's component devkit has functions that coerce component input into a specific type, e.g. coerceBoolean for booleans.
This lead to a lot of repitition of the following pattern in our code:

export class FooComponent {
  private _isBar = false;

  @Input()
  public get isBar(): boolean {
    return this._isBar;
  }

  public set isBar(isBar: boolean) {
    this._isBar = coerceBoolean(isBar);
  }
}

To simplify this, we created coercion decorators. The previous code is equivalent to:

export class FooComponent {
  @Input()
  @coerceBooleanProperty()
  public isBar = false;
}

We wanted to ensure typescript enforced the type of the property, otherwise these decorators are a step back with respect to type safety.

Having decorators play into type inference would be a great solution to our problem! In the mean time, we have created types that allow us to write typed decorators. The following stackblitz shows our approach:

This is not as powerful as TypeScript#4881 proposes, e.g. it cannot modify the type of the property, but it does cover our specific use case. I hope this can also help in clipanion.

Kind regards,
Bram

[Maël Nison]

I like that! Basically it's exactly the opposite - instead of saying that the decorator provides the type, you instead let it check that the property name is the same as one of the properties in the class that's compatible with the expected type. Smart!