The phrase “horribly wrong” seems a bit strong, but I do think there is one fundamental change you could make to your world view that would melt all of these concerns away (with one potential exception):
Consider lifecycle events strictly a view layer concept. Never try to do data layer things in them.
If you haven’t seen this post before, it’s the first thing I remember writing on this topic, so some of the syntax may be obsolete at this point, but I believe the basic concept still stands up: manage your business object data flow independently of how the framework chooses to present the view layer.
The idioms in that post should take care of your async pipe issue, and the last one involving OnInit, because you will no longer be using ionViewWillEnter to set resourceId.
The middle one with the camera stream is the potential exception. Ordinarily, views shouldn’t care whether or not they’re being cached out of sight, but I can see how something like an external camera input would be an exception there. I think your idea of getting the element that provides the camera stream out of the DOM when it shouldn’t be there sounds like a reasonable approach.
The fundamental problem, as I see it, is that bare scalar properties have no way of communicating when their values are reliable. Trying to achieve that ability (to convey the notion of “freshness”) is arguably the #1 reason that Angular is so tightly coupled with RxJS in the first place.
Every time you share bare scalar properties (like your resourceId) that can change, you’ve laid a trap for yourself. You have to come up with some out-of-band way to signal changes, lifecycle events seem close enough, you hitch your wagon to them, the wheels come off, and before you know it, you’re dead of dysentery on the Oregon Trail.
When these data are no longer shared nakedly, but instead as Observables, the problem goes away. You can push updates (with next on a Subject, for example) whenever needed, and all clients receive updates seamlessly.
For technical reasons, there are things you can’t do in component constructors. Everything that can be done, I would suggest doing. That leaves things like dependencies on bound input properties that haven’t been bound yet for lifecycle events, and in that instance, Angular will manage the data freshness for you.