Signal and the new input?

[DSLibner]

Maybe a move to signals would be a good idea. It would allow to go zoneless and improve change detection across the board. Also it's were the angular team is focusing on moving towards, even store is being migrated to signals.

[stephanrauh]

I haven't made up my mind when I'm going to migrate to signals - but it's only a matter of time.

However, I don't want to introduce breaking changes, at least not without a generous transition phase. What's your suggestion, how should I deal with backward compatibility?

[DSLibner]

Well I would start by changing the @input to input, that should not introduce any breaking changes. And then when it comes to the signal migration you could make some wrappers that replaces the current attributes that just sets the signal and the same with getting the value, while providing the option to move to using the signal natively. Then you can deprecate the wrappers which would give people all the time they need to migrate.

[stephanrauh]

Migration to functional input() is a good idea. I think there's even a schematics for that. However, adding wrappers sounds intimidating to me. At the moment, there are 104 @Input attributes...

[DSLibner]

Yes there is schematics for that and a lot other best practice migrations.
You could also skip the wrapper part and make it a new major version 3.0.0 and then do dependency updates on a 2.x.x version.

[stephanrauh]

Interesting - I'm using signals on a daily basis since a couple of weeks or months, and even so, I missed that the template syntax doesn't change. So I'll probably publish a new major version with breaking changes. And I'll try to write a schematics doing the migration. I doubt I can write the perfect migration schematics, but I'm pretty sure I can take the sting out of the migration.

[DSLibner]

Sounds great, thanks for doing all this great work!