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.
But, here’s the deal. “Just because you can, doesn’t mean you should.”
The thing that makes me most nervous about Angular is that it is structured so that you can write some really clean code. But, you don’t have to. Which mean most won’t.
So, here are a few things you need to know about TypeScript that will make you a better Angular developer.
As consistent readers of this blog are aware, I’ve fallen in love with Functional Programming. But I also live in a primarily Angular/TypeScript world where some code is still Object Oriented and other code is more Functional in nature. And while TypeScript lets you do some Functional things, I’ve found it hard to force functional concepts in TypeScript. So, I’ve gone searching. Wouldn’t it be great if there were some sort of flag you could set that said, “Hey compiler, I’m in ‘Functional’ mode now!” And the compiler would make sure that you never used a conditional statement, never accessed hidden parameters, and never mutated state?
Well, I think I’ve figured out some of how to manage all of this using nothing more than TypeScript and some TSLint rules.
In the old world where all of our pages were on the server and every change on the client side required a full round trip to the server, each page was a unique URL on the server. In the SPA world, we only load one “Page” from the server and the client takes care of making it look like we have moved from one page to another.
When done well, we can create pages that reuse existing content on the screen causing a minimal screen refresh while still allowing the user to link to a specific “Page” in our application.
These “Pages” are called “Routes” As in, here is the route to some code I want to execute.