feat: switch to signal inputs

[arturovt]

No description provided.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[frezo00]

@arturovt Isn't (one of) the purpose of signals to avoid using the ngOnChanges life-cycle hook?
Also, some predefined initial values for non-required inputs would be nice to add, especially for boolean values as the undefined seems as an invalid type.

[arturovt]

I haven’t heard of avoiding ngOnChanges. If an effect running on a signal change may internally update some other signals, this will lead to a runtime error, or capture other signals being read.

[frezo00]

Please, read Netanel's article about signal inputs: https://netbasal.com/revolutionizing-angular-introducing-the-new-signal-input-api-d0fc3c8777f2
There is a top highlight saying:

This update eliminates the need for the ngOnChanges lifecycle hook, as computed properties now automatically update with input changes.

Therefore, many of those protected properties, that are being initialized inside the ngOnChanges can be computed from the corresponding input signals.
With that reactive approach, we can reduce a lot of side effects and have less code written with the same functionalities.

[NetanelBasal]

@frezo00 eliminates !== avoid

[frezo00]

Sure, my mistake in the first comment, should have used another verb 😅
But generally, the current ngOnChanges logic could be replaced with the usage of the computed signals (mostly) and the effect in the constructor (for side effects).
For example, the this.props is an ideal candidate for a computed signal which is not added in this PR.