It is not uncommon in our programming endeavors to need to replace one element in an array. Using old school procedural programming, this would be relatively easy. Loop through the elements, when we find the one we want to replace, change the value. Basic for/next loop with a conditional statement.
But when you move to a more functional way of programming as we need to do for NgRX, or are encouraged to do to make our code more testable, the problem becomes less straight forward.
The initial solution you might try would be to just run reduce() against the array. But if we do this, we still need to put that nasty conditional within our reducer function. This is something we’d prefer to avoid. Yes, it will work. But it isn’t Functional. This problem has bothered me for months. I’ve finally spent the time to figure out the solution.
This week, I discovered that NgRX 4 had released. Yeah, we skipped over version 3 here too to get in sync with the Angular version numbering.
There is a pretty complete upgrade guide that you can find here. But, the upgrade guide assumes that you are creating Actions by instantiating a new Action object rather than returning a literal as I’ve been instructing.
So, in this week’s post, I plan to cover the exact steps I recommend going through to upgrade to NgRX 4, why I don’t think instantiating an Action if the right way to create new actions, and some possible enhancements you can make once you’ve upgraded to the new version.
The problem with using callbacks is that you can end up with “Callback Hell” where you have callbacks inside of other callbacks. Our code becomes messy and difficult to reason about.
To try to flatten this situation out, promises were created. Instead of creating a callback function and passing it into the asynchronous function, the asynchronous function returns a promise that has a function we can pass our function into. This function can return yet another promise. The result is that instead of having nested callbacks, all of our callbacks live at the same level.
However, in the process, we lost the ability to cancel an asynchronous function using callbacks. Most of the time, this was not a huge concern, but in the case of AJAX calls, we did end up making more request than we really needed to. Most people never even recognized this as an issue. But if you go and take a look at some of your older code, you will see that you have several places where the code would work more efficiently if you were able to cancel a call that was being superseded by a new call.
What? You haven’t seen these? If you have and you know how they work, you can skip this next section. But, if you haven’t, pay careful attention because this next section is critical to understanding how Observables work.
There must be some evil plot to keep this information a secret because whenever I search for how to use RxJS Marble Testing all I see is how to use it to write tests for RxJS. Well I’ve finally “cracked the code” In this article you’ll learn the basics of RxJS Marble Testing and how to apply Marble Testing to your own code.
What is sad is that this reality is lost on so much of the Angular community. When I listen to podcast where they talk about any of these concepts individually, Function Reactive Programming (FRP) is barely, if ever, mentioned.
But the scary thing is this, there are many people who are going to use the new Angular the way they used the old Angular and they will completely miss the main advantages. They may even jump from Angular to React or (even) Aurelia. And that’s just picking on the most recent frameworks. Some will want to go back to Egypt and decide jQuery is a good choice!
Functional Reactive Programming is not just a hot new model. It solves a lot of problems.