Whether to use a Promise or an Observable is a valid question. Let me show you a little hint for deciding when to use what.
This is the first article of the mini-series ‘Condensed Angular Experiences’. We will explore concepts in Angular that seem simple but are very powerful and critical for the application architecture.
A big topic in SPA development is how to manage your application state. The solution often presented is the NgRx library. This article is not a guide, endorsement, or thorough evaluation of the technology. Instead, I want to share some experiences I have made with the store and give some references if you consider picking it up or already using it in a project.
In the first and second part of this small series, we have discussed implementations that have flaws and can introduce side-effects to our data flow. We have learned how combining our streams and modeling our our data flow to yield a single result helped with solving the introduced problems.
This is the second part of a small series, in which I want to share some pitfalls we discovered multiple times in code reviews over the years, as well a few patterns we identified as helpful. In the first part we discussed how nesting subscriptions can be harmful.
Working on numerous Angular projects over the past couple of years, it has become evident, that a lot of developers still have a hard time working with RxJS which finds its use in Angular. While RxJS is a very powerful tool, it comes with a lot of operators and a whole paradigm shift. Even experienced developers can be hung up on its intricacies and more than 100 operators.
