Lacking @Tommertom’s gift for diplomacy, I’m going to state more emphatically that there has to be a better way to achieve the overall goal than reinventing the flaws of events.
I cannot tell you how many thousands of times I have misspelled string constants and sent myself down needless rabbit holes. Computers are way better than humans about detecting this, so I think we should defer to them on this front.
There is another gigantic problem with this design: it obliterates encapsulation. Pages should not be calling functions in components. Period. Pages should not even know what functions components have. Components, likewise, should not know anything about the environment in which they are hosted. If I can’t strictly follow this rule, then I decide that I have made a mistake about where to draw the lines between page and component.
There are two good ways to tell a component something from outside: changing the value of a bound
@Input property, and via a service that the component injects. I have no idea which of these makes more sense in your situation, because we are deep in XY problem territory here.
The post about managing user profile state that @Tommertom quoted describes how one would do this when the message is “some application-level state object has changed, and component needs to change how it’s rendering to reflect that”. An example of the other major category would be a situation where you have a master/detail display on a single page, in which case declaring an
@Input property on the detail component would make more sense, and then when a new item is selected, point the
@Input at the new selection.
ngOnChanges will fire in the child component.