feat: Migrate decorators to signal queries

[n-elhk]

Migration of the following decorators:

• @Output => output()
• @ViewChild() => viewChild()
• @ViewChildren() => viewChildren()
• @ContentChildren() => contentChildren()
• @ContentChild() => contentChild()

Migrate to new methode for dependency injection :

constructor(myService:MyService){} => myService = inject(MyService);

[HarelM]

Is this PR ready for review or still in progress? Can you change it to draft and use "request for review" when completed if this is still in progress?

[n-elhk]

Yes this PR ready for ready for review, another PR to is needed to change the @Input decorators as this requires more time

[HarelM]

Would it be better to wait for the input change as well before merging this? I would prefer to have everything in the same PR so that the code won't be partially "new style" and partially "old style". Does it make sense?

[n-elhk]

In fact, it doesn't change much, but it's true that it's better to have everything in the same "style".

[HarelM]

Thanks for the input, I'll keep this PR open and wait for the input changes.

[n-elhk]

I made the changes , PR is ready for review

[HarelM]

I haven't finished the review yet, sorry, I will continue tomorrow...

[HarelM]

I've finished my review. Thanks for all the work around this PR!! A few general comments: I see places that use destroyRef.onDestory and other places which we use ngOnDestory, I think we should use the same for everything if possible.

There are places that uses signal for what were private properties, can you elaborate on my use them in this case?

This is a very large change, I've changed in my app a places with takeUntilDestoryed vs subscription list and got a nasty error. How do you know everything is working as expected? I've not sure the tests coverage here is really covering all the components unfortunately...

[n-elhk]

I saw that the unit and integration tests did not cover the entire app to check if I didn't break anything. I compared it with what is in production by replaying the showcase.

[HarelM]

There are a few last comments. Sorry for the long review...

[HarelM]

Can we just composition instead of inheritance for the sources?

[n-elhk]

Done

[HarelM]

Ok, I'll do another final review, if I won't see anything critical I'll merge this. Thanks for all the work on this @n-elhk !!

[HarelM]

Can you explain the change from a local property in a class to a signal type? What's the pros and cons of this approach?