There seems to be a lot of confusion about Implement NgRX 4 and above in an Angular application.  Some of it I’ve contributed to because NgRX 2 isn’t quite the same as NgRX 4 and as I’ve transitioned, I’ve learned better ways.  In other words, I was wrong and I’m correcting my mistake!  Below is the correct, NgRX approved way, of implementing NgRX 4.

If you are looking for information about how to convert to NgRX 4 from NgRX 2, you can visit my previous article, How to Upgrade to NgRX 4.

Before we get started, make sure you have TypeScript 2.4.x or above installed in your local project.  The CLI may complain, depending on what version of it you are using.  But, NgRX 4 requires us to use TypeScript 2.4.x. You should also have RxJS 5.4.x or above installed.

You will also need to install @ngrx.  You can do this using the following NPM command:

1

npm install --save @ngrx/store @ngrx/effects

And finally, I’ve found that I need to use the –aot switch both when I’m using production and development builds, so you’ll want to add that to your scripts in your package.json file.

Read More

Since I don’t seem to have a blogs worth of any one topic to write about, I thought maybe something more along the lines of a cluster of small tips and tricks might work.  Since I’ve been writing my Angular book over the last couple of weeks, there hasn’t been much new that I’ve discovered worth sharing.  But there are a few small discoveries I’ve made.  This week, they center around NgRX Effects.

Photo via Visual hunt

Read More

For the last 18 months, I’ve been working for an organization that has what some might consider a unique requirement.  Because of where our application’s data is sourced, we need to aggregate data on the client side rather than on the server.  What this means is that for any one screen, we may make multiple calls to the server to grab all the data we need.  Fortunately, because we adopted NgRX early in our adoption of Angular, we could avoid a lot of the headaches associated with client-side aggregation.

Read More

As I’ve been interviewing for a new contract, the question, “How do we Upgrade to Angular from …?” has come up several times.  And as I’ve thought about the question, several patterns have emerged.

Read More

I made a tweak to my Angular code process over the last month or so that has resulted in greater productivity in my development environment and fewer bugs.

Now, I didn’t make this change because I thought it would improve my productivity.  At least that wasn’t the primary reason.  I made the change because I thought it would reduce the chance of introducing bugs into my code.  And while it does reduce the number of bugs in my code, the result has been generally improved productivity.

What is this great secret?

Read More

Over the last week I’ve gradually come to the realization that the fundamental reason why most people have trouble with JavaScript is because it doesn’t fit their mental model of how programming should be done.  This isn’t to say that most programmers don’t manage to achieve their end goal.  But if you sit back and take an objective look at the code we end up writing, you have to admit, the code ends up being quite ugly.

Now, this isn’t a dig at the way we’ve been doing things.  We’ve all been doing the best we can with what we have.  But, the JavaScript world has progressed and there is a better mental model that has developed and should even be expanded which will allow us to develop more complex and feature rich applications now and well into the future.

Read More

While testing Components is possible, it is not easy and is often pointless.  Using the Model View Presenter pattern, or a variation of it, solves the problem.

Here’s the deal. Long time readers of my blog know I’ve been a proponent of Unit Testing for a very long time. While I was learning React, I went through the exercise of trying to write test as I was learning.  Now, the great thing about Angular and React is that it is possible to test your components.  The problem with testing components is that you are either testing that your HTML ended up in the right spot, that Angular directives did what they should, or you are evaluating the DOM to verify that component logic worked.  In most cases, putting tests that do any of these at the component level is the wrong way to test.

Read More

If you’ve been programming JavaScript based applications for any length of time, you’ve probably already made the progression from callback hell to promises, but just to recap.  Whenever we make any kind of asynchronous call in JavaScript, we need to provide a callback function to the call so that, when the call completes, the function can be called with any resulting data.  Function calls you may typically make that need this kind of feature are setTimeout(), setInterval(), and AJAX calls using the various libraries that support this.

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.

Meanwhile, some additional functions were added to JavaScript Arrays.  Maybe you’ve seen some of them?  map(), reduce(), and filter() are three of the more common functions.

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.

Photo via VisualHunt.com

Read More

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.

Read More

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.

Photo via Visual Hunt

Read More