At my job we went from using observables for everything to literally questioning every single one that shows up in a PR. Most of the time they don't need to be there. Several spots in our app are nigh unusable/untestable messes because of the side effects that get caused from subscriptions. Eg, you make a change in one place and something else totally unrelated gets updated. Obviously the implementation was totally wrong there but I tend to believe in the idea of a "pit of success" with framework api's. With observables, it's a giant foot gun if you don't understand what you are doing and you are better off using something more stateless like a promise or just a simple javascript object reference shared via singleton service or something. If you aren't careful about managing your "source of truth" you are gonna have a bad time. Then of course theres remembering to unsubscribe from them... memory leak anyone?
While I think they are a powerful tool, I find that a lot of developers get them confused as a drop in replacement for promises and do things like nest subscriptions etc. For most standard CRUD apps, either do as the author suggests, and use an async pipe in your template, or, convert them to promises as soon as possible.
What are they good for? Streams of data. Web Sockets, iframe post messages, event handlers for instance. Anything that is actually real time and makes changes without deliberate action.
While I think they are a powerful tool, I find that a lot of developers get them confused as a drop in replacement for promises and do things like nest subscriptions etc. For most standard CRUD apps, either do as the author suggests, and use an async pipe in your template, or, convert them to promises as soon as possible.
What are they good for? Streams of data. Web Sockets, iframe post messages, event handlers for instance. Anything that is actually real time and makes changes without deliberate action.