Fire change events upon initialization

[magneticflux-]

Feature Description

Components that have change events should fire them when their initial value it set.

Use Case

This would let reactive observers of that value receive an initial value, making BehaviorSubjects able to be used to track component state.

Currently, to find the value of a component just after init, the component must be injected into its parent using @ViewChild and then the value must be manually extracted.

Otherwise, the BehaviorSubject's initial value must be specified in the component's code as well as in the component's template, which is prone to becoming desynchronized during refactoring due to the duplicated code.

A concrete use case example

I want to receive MatPaginator page events to update my query. I don't want to have to manually trigger it the first time because that would require an additional layer of event handling and/or some spaghetti code, it should just be triggered like every other change event since the value is changing from being absent to being present.

Implementation Considerations

This could be a flag that defaults to false to prevent breaking existing applications, but I don't think many existing applications would break from this change unless their event handling is very fragile.

[crisbeto]

This seems a little arbitrary because we've had multiple issues in the past where people have requested the exact opposite: only dispatching change events if the value changed as the result of a user action.

[magneticflux-]

I searched for prior issues on this topic and found #1125 which refers to inconsistency rather than strictly change-on-init or not. In that issue, I noticed that @jelbourn stated that change-on-init was unequivocally a bug, and I'm interested in hearing the reasoning behind that design decision.

I think that firing a change event on init when defaults are set is the more flexible approach, since users could:

1. Simply drop the first event using RXJS skip(1) and get the old behavior
2. Enable/disable a flag to control the behavior

[magneticflux-]

@crisbeto I'd be happy to start work on a PR with these changes once we have a solid plan of what needs to be done!

[devversion]

Yeah, I'd agree with @crisbeto. I think our understanding of this was that we want to match native elements as much as possible. i.e. input[type=checkbox] does not emit change for its initial value either.

See: https://stackblitz.com/edit/comp-17398?file=src/app/app.component.ts

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[crisbeto]

We're in the process of cleaning up our issue backlog. I'll close this issue, because there hasn't been any activity in a long time and the current behavior is intentional.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}