Maybe this is all obvious to you, but since I don’t see anyone talking about this when I search for “how to do NgRX” or the various variants, I thought I’d call it out in this weeks post.
If you haven’t been following along, you’ll want to review my previous posts on NgRX.
Over the last month or so, I’ve been presenting the basics of how to use NgRX/Store with Angular. In the past, I’ve praised the virtues of Reactive Forms, also known as Model Driven Forms. These along with RxJS make up the pillars of Functional Reactive Angular Programming.
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.
This past week I was talking to a guy who is graduating from College and looking for a job. He asked me what most people ask at that point in their career. “Everyone wants experience, but how do you get experience if no one will give it to you?”
What is interesting is that for all the advances in the 30 years since I started my career, that question is still the main question every graduate asks.
Now, before I get started, I want to make sure we are clear. These tips may or may not work for you. They are what I would do, and in large part are what I did 30 years ago, just updated to be appropriate to the current technology. How well they work for you are going to depend on a lot of different factors, not least of which is how much effort you apply. They are also very much based on my culture here in the USA. If you are looking for a job in another country that is dissimilar culturally, you may want to ignore this advice completely. But, I’ll also say this. If what you are currently doing isn’t working, what do you have to lose?
This week, I want to demonstrate some ways you might use NgRX in your own code.
Last week we went into a lot of detail about how the NgRX system should be wired together. Here is all of that in picture form.
A component fires an event to either an effect or a reducer using an action. If an effect was called, it fires another action which is normally picked up by a reducer. The Reducer mutates the state which then gets placed in the store. “Magic happens here.” You don’t write any code to get it to the store other than that you create a reducer. Anything that is observing the table in the store that got changed will get notified via RxJS observables and the cycle is complete.
Note that the action you dispatch can be handled by either an Effect, a Reducer or both.
Most of the time, we think of NgRX as a way of handling CRUD operations. We need to see the current record so we fire off a LOAD action that uses an effect to retrieve the data from the database. Once the data comes back, we return an action that tells the reducer to put that new data into the store. Since our component is observing the store, it updates the screen with the new values.
If we need to add a record, we fire an ADD action. If we need to delete we fire a DELETE action. If we need to update, we fire an UPDATE action. Each of these are picked up by the Effect, which then fires an action that places new state information in the store via the Reducer.
When most people think of how to use NgRX or any similar pattern, they immediately think of the CRUD pattern I mentioned above. But, we don’t have to start the Action chain from a component. For that matter, we don’t have to listen to our Store data from a component either.
One way I’ve implemented NgRX that solves a lot of common issues is that I’ve created a wait state component that shows when a count variable has been incremented and doesn’t show when the count is zero. Since Store is Injectable, I can increment and decrement the count from just about anywhere. Most often I increment it from an effect just before I make an AJAX call and decrement it in a finally() block of the Http observable. I have a start() action that increments the count and an end() action that decrements the count and ensures that I never go below zero. I can start off multiple asynchronous processes which will all increment the counter and decrement the counter appropriately. The wait state GUI displays until everything has finished.
This is OH! So much easier than how we’ve had to handle this problem with other design patterns. I’m not saying it couldn’t be done, or that it was even particularly hard. But this way is easier.
Another place where you might want to present information but trigger the display from just about anywhere is with error handling. In the code I work on, I have a modal popup component that displays whenever my error collection has something in it. Anytime I need to display an error, I add the error to the collection via an Action and it magically displays. The great thing about this mechanism is that regardless of how many errors I send to the collection, they all display until I close the window, which clears out the collection.
Most page state is handled by the fact that we’ve stored the data into a database. But there are times when we want to come back to a page we had been working on previously and we want it to display with the data that was on it at the time we left.
Or maybe you want to work on a series of pages prior to saving so that everything gets saved as a set.
No matter. You can use NgRX to store everything into the store and a separate action can trigger an effect that pushes that data to the database.
Or, as is the case in an application I’m working on, I’m using a form to search a database. When I come back, I want the same search fields and I want the search to reinitialized. In my particular case, I don’t have a search field. You change a field, a new search is automatically initiated. This case is just a little bit more complicated than what we’ve looked at so far.
In order to keep the state information available so that it is there when I come back to it, I need to store that information in the search table via the Search Reducer. So, every time something changes in the Search Form, I send off an action to the Search Reducer so that the change can be recorded.
Meanwhile, the Search Form also is listening to the Search Table so that when it comes back it can put the changes in the form, and it can send an action to the Search Results Reducer telling it to search for the information. When it gets the results, the Search Results Table picks them up and since the Search Results Component is listening to the Search Results Table, they display.
If I leave the page, the Search Form grabs the current search parameters from the Search Table and Fills the Form and sends the action to the Search Results Reducer and the page is back where we left it.
The point is, NgRX isn’t just about basic CRUD forms and because there are multiple ways you can mix and match the parts, even your basic CRUD implementation has a lot more flexibility than you might be used to.
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.
If you are using Angular(2+) and you are looking for an easy way to layout your components that gives you lots of flexibility and very few restrictions, you owe it to yourself to checkout Angular Flex Layout. While it is still in Beta, the framework is quite usable. I’ve been using it in one of my projects and I’ve been quite happy with the results.
Unit Testing Angular(2+) with JSDOM can be problematic unless you know the secret handshake that allows ZoneJS and JSDOM to coexist.
The great thing about Angular is that you can write Unit Tests from the presentation layer all the way down to calls to the server. But up until now, you either ran those tests in a browser, which doesn’t work well in a CI system, or you used PhantomJS, which tends to be REALLY slow! But there is a better way, and hopefully, by the time this post goes live, the patches needed to use JSDOM will be available. If not, I’ll show you the hack that I’ve found works and the pull request I’m hoping will go live.
There are two twin evils that I see in the programming community. The first is the programmer who knows what he knows and has no desire to learn more. I call these, “coasters”. And then there are the programmers who are so curious that they try to learn every new thing that comes along, with no focus. The interesting thing is, both of these types of people end up at the same place. Out of work. The cure for both is the same. Being Awesome.
You know, you think the whole world knows something is true until you hear someone people respect say something really dumb. The three JavaScript fallacies I have here are actual statements I’ve heard over the last week during a discussion about Angular2 and Rect. What makes these fallacies particularly interesting is that they sound plausible. In fact, there are time when they are even true. But in the larger context of a JavaScript application they are nearly always false.
So, here are 3 JavaScript Fallacies you may still believe that you may want to reevaluate.
To say there are secrets to being a confident programmer may seem a bit over the top. But, you would be surprised at what makes a programmer seem confident, how you can be more confident, why confidence is no real indicator of truth, and why you need to arm yourself against confidence.