You can use ngOnChanges callback to react to changes in the angular framework - i.e. if bindings/@Input()s/etc have changed and you want to do something special there when they change. But for just generic DOM changes happening outside of the angular framework that wont work (since angular does not know about random other DOM stuff going on elsewhere in the page and outside of the framework). E.g. if there is some static JS code in the page doing stuff to the DOM, angular won't trigger ngOnChanges for that.
For your approach, that looks reasonable to me in the 5 lines we have to look at :-) ... so long as you are consistent with the SelectionService and make sure all the changes go through that, you should be fine and your component will get all the updates.
This sort of requirement for consistent management of things like this - i.e. the application state - is a weakness of Angular I think. It is easy to start simple and end up coding yourself into a corner with god services etc. I have used a thing called NgRx in the past for managing state - its the redux pattern and seems to be quite good at making sure state is a bit more sane and well-mananged in the app (at the cost of some boilerplate). One day I hope that there is an official state management mechanism.
Thanks, that sounds like the right approach. I don't need to react to all DOM changes, but I have one jolly callback for changes to my one big happy god-owns-the-user-owns-the-world object (the observable), but the component has view-level properties like hiding and showing details, zoom and pan, etc, that aren't in the observable model, and I'd still like to redraw the canvas when they change. It doesn't take long to draw, but I just don't want to miss any updates, or have to pepper the code with explicit calls to redraw it every time I think something might have changed (causing a lot of pointless redrawing).
Fortunately my app is simple enough that I can just redraw everything whenever something changes, as long as I'm not doing it 37 extra times.
For your approach, that looks reasonable to me in the 5 lines we have to look at :-) ... so long as you are consistent with the SelectionService and make sure all the changes go through that, you should be fine and your component will get all the updates.
This sort of requirement for consistent management of things like this - i.e. the application state - is a weakness of Angular I think. It is easy to start simple and end up coding yourself into a corner with god services etc. I have used a thing called NgRx in the past for managing state - its the redux pattern and seems to be quite good at making sure state is a bit more sane and well-mananged in the app (at the cost of some boilerplate). One day I hope that there is an official state management mechanism.