Angular DX syntax proposal - more decorators 😅

some.component.ts

@Component({ /* ... */ })
export class SomeComponent {

  // streamifies input
  @Input$() prop: Observable<string>;
    
  // lifecycle notifier as an Observable stream  
  @OnDestroy$() destroy$: Obseravble<void>;
    
  // lifecycle hook as decorator instead of implements interface  
  @OnInit() 
  init() { // could be any method name when used with decorator
    
  }
    
}

Love this, I also use RxJS heavily and this would make my life oh so much easier.

If anyone would make it into a reality, how would you do it? For example handling initial values. Would you allow making the subject on your own have the decorator do it?

I'd come up with something like this from the top of my mind.

@BehaviorInput$('hello') foo$: BehaviorSubject<string>;
@ReplayInput$(1) bar$: ReplaySubject<string>;
@Input$() zed$: Subject<number>;

But what if I'd like some throttling on this input? I can't really have the user to define a full input pipeline, I'd need a separate reference to the source subject and the pipeline so I'd may settle with 1 decorator and an options object:

@Input$({
  initialValue: 'hello', // would make it create a BehaviorSubject
  replayCount: 1, // ignored if previous is defined
  throttleTime: 300, // Adds a throttleTime operator with `leading` and `trailing` emits set to true
}) foo$: BehaviorSubject<string>; // Sadly you'd have to type this up yourself depending on the option...

But this has conflicting configurations so in the end I'd probably have all three of them as separate decorators and then an additional options for pre-added operators. Maybe a 2nd parameter (initial: T, config: Config), or to replace the first one (config: T | Config) These additonal options (like throttle)

Hey @AlexAegis !

Thank you very much for you great input! There is definitely complexity that hides at the edges as mentioned by you, initial value, ...

Some thought, something as simple as @Input$() prop$: Observable<string> should be simple, yet powerful enough to achieve desired results, eg could be used with this.prop$.pipe(throttleTime(300), share({ connector: () => new ReplaySubject(1) })) instead of increasing the API surface of the decorator itself.

Love this, I also use RxJS heavily and this would make my life oh so much easier.

If anyone would make it into a reality, how would you do it? For example handling initial values. Would you allow making the subject on your own have the decorator do it?

I'd come up with something like this from the top of my mind.

@BehaviorInput$('hello') foo$: BehaviorSubject<string>;
@ReplayInput$(1) bar$: ReplaySubject<string>;
@Input$() zed$: Subject<number>;

But what if I'd like some throttling on this input? I can't really have the user to define a full input pipeline, I'd need a separate reference to the source subject and the pipeline so I'd may settle with 1 decorator and an options object:

@Input$({
  initialValue: 'hello', // would make it create a BehaviorSubject
  replayCount: 1, // ignored if previous is defined
  throttleTime: 300, // Adds a throttleTime operator with `leading` and `trailing` emits set to true
}) foo$: BehaviorSubject<string>; // Sadly you'd have to type this up yourself depending on the option...

But this has conflicting configurations so in the end I'd probably have all three of them as separate decorators and then an additional options for pre-added operators. Maybe a 2nd parameter (initial: T, config: Config), or to replace the first one (config: T | Config) These additonal options (like throttle)

Maybe the type of Subject could be modified within the Input$ options. And throttle and other could be added through pipes. I think the Decorator itself should not have to many options.