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?

[HarelM]

I think this looks good. Thanks for all the hard work on this! Is there anything else that should be done before we merge this?

[marcjulian]

This looks awesome.

I tested it with zoneless provideExperimentalZonelessChangeDetection() and the map works after removing this.zone.onStable.pipe(first()).subscribe(() => { in MapService.setup.

[n-elhk]

For me, everything seems good. As to suggest @marcjulian we can delete zone.onstable so that we can use the lib in zoneless mode

[marcjulian]

Yes I guess we can remove zone.onstable and usage of NgZone service in another PR

👍

[HarelM]

Last two comments:

1. Please add a changelog entry
2. If you can answer the last open review regarding the on destroy. https://github.com/maplibre/ngx-maplibre-gl/pull/178#discussion_r1661241243

THANKS!

[HarelM]

It would also be good to upgrade angular to 18, but again, as part of a different PR.

[HarelM]

Also, I didn't get a good answer to the following question:

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

Can you please share your thoughts about it?

[marcjulian]

It would also be good to upgrade angular to 18, but again, as part of a different PR.

Its already updated to Angular 18

[HarelM]

Right... Then we need to release a new version to match it, maybe even before this PR merge to be able to test it separately...

[HarelM]

I've released the 18.x version. Merging this now.