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.
This past week, I needed to be able to upload an image in my application to the server as a file so that I could crop it and upload it.
Now, uploading an image that you pulled up using the file upload control is relatively straight forward. But, in our case, the image we want to be able to upload didn’t always come from the user’s file system. This causes two problems.
First, you can’t crop an image you retrieved from a different URL using the HTML Canvas because of Cross Origin restrictions and second, you can’t upload the file using the standard file upload mechanism because you didn’t get it from the file system.
If you are programming in Angular and haven’t tried Model Driven Forms yet, I’m assuming that is because you’ve not taken the time to try to learn it. In this article, I am going to try to convince you that the Model Driven Form based approach is superior to Template Driven Forms and that the only people that are still using Template Driven Forms are people who either have not been enlightened or lazy.