This week, I thought I’d collect a list of unrelated tricks and tips I’ve learned over the last couple of weeks into one post. Unless you love to read documentation, or you’ve run into problems that these tips solve, I’m guessing you don’t know most of these.
But first, the big new this week…
Angular Version 4 Released
You may have already seen this. You can read all about it on their blog. Yes, it makes the code smaller and faster. Yes, it implements an “else” for *ngIf. Yes, it works with the latest version of TypeScript. But the one change I’m most looking forward to is the “source maps for templates.”
If you’ve ever seen the error in your console window indicating an issue with your template with some obscure line number that has nothing to do with your template code, this should be great news for you as well. Imagine being able to actually track down those errors in some more intelligent way than trying to guess exactly what line is causing the problem.
There is one small breaking change in this release and that is that they’ve moved the Animations package out of Core and into its own location. Since we’ve decided to wait to hear from our control vendor to see if that is going to have any impact, I can’t report on how much heart burn that’s going to cause you.
The Official Name of Angular
So, finally the Angular team has come up with an official way of distinguishing between Angular 1 and everything after it. The official name of Angular 1 is “AngularJS.” Everything else is just “Angular.” For now, I’ll keep referring to it as Angular 2 until it actually catches on.
Periodic Production Compiles
For the purposes of this article, I’m going to assume you are using the CLI, but if you are doing all of that work by hand, most of what I have to say will translate to what you are doing.
A couple of weeks ago, we ran into a memory leak in our code that evidently is a known Angular 2 issue and only appears when you compile for DEV mode. This caused us to go down the path of actually trying to compile our code in Production mode where I found that some of my code wouldn’t compile.
As it turns out, when you compile in production mode it verifies that code more strictly so that it can use Ahead of Time compile if you choose to do that.
Moral of the story is that you probably want to always work in production mode until you have an issue that you want to track down, where you can switch to DEV mode for the debug session. Or, at the very least, compile for production prior to running the code in debug mode just so you are sure you can compile. I prefer always running in production mode so that I’m sure the code is working correctly.
Direct Access to CSS
ng serve --extract-css
I personally never need this because my files are organized in such a way that I know where stuff is, but I can see where this would be helpful if I wanted to track down CSS in someone else’s code.
Accessing the Component Host Element
If you need to access the host element for your component using CSS, the selector you want to use is
When you use this, keep in mind that your element has no default style so you will need to provide all of the styling. Otherwise, it will show up as an empty element with overflow set to show. This is probably not what you want.
:host, you can avoid creating an inner
DIV in your component just so you can display everything else. The host element can function as that
You can access the host element directly from your typescript using
You will need to inject
ElementRef in your constructor for this to work.
Finally, if you need to bind to events on the host element, you can use the @HostEvent() attribute prior to the function that is going to handle the event
Accessing Child Components
If you need to style a child component from one of your components in some way that is unique from the rest of the system, you will need to add CSS in your component. The proper way to access the child component is by using this directive:
:host >>> child-component
child-component is the tag you are using to load the child component.
The trick is the triple > selector.
To access the child component in your TypeScript, all you need to do is give the element you are interested in a variable using the #variable identifier. Notice, this is standalone. We are not using the ID of the element, although it could have the same name if you wanted.
Then, in your typescript, you’ll declare a public variable that is prefixed with the
@ViewChild() decorator. There are several ways that you can use this. But using the variable method that I’m describing here, you just specify the variable name, in quotes.
@ViewChild('variable') variable: ElementRef;
Everything is an
ElementRef. If you need to type it more strongly, you can.
You can use whatever variable name you want to for the member variable. But I normally name it the same as what I named the element.
The problem is, because the elements we want to animate in and out often don’t exist in the DOM at the right time, using straight CSS to do the animations is problematic or impossible. This is where the Animations package comes in.
On the project I’m working on now, I define my animations in an animations directory and apply them to my components as needed. So, for example, I have an animation defined that fades my pages (routes) in and out. It is defined once and applied to all my top level components.
Another rather new CSS development is the flex-box layout system. This solves all kinds of problems that we’ve had in the past. The problem is, it is so new that it doesn’t work exactly the same way on all of the browsers.
What the flex-box layout system does is that it allow us to layout rows and columns specifying the width of the columns or rows within them. The Flex Layout package takes that concept and expands on it as well as making sure it works the same way across all browsers.
First, instead of using CSS, it does all of the same work using directives. This puts the layout closer to the code we want to impact without violating the single responsibility principle. Think about it. Layout stuff like this is generally component specific. Not something we want to generalize beyond that. In the old days, we did need to generalize layout like this more because we were applying it to multiple pages. But our common layout is typically handled by our top most component in a SPA.
Beyond all of this, it also allows you to specify when a particular directive, or element, should apply based on screen size. So, it takes the Bootstrap grid layout system and makes it even more powerful. I’ll probably still use Boostrap for what a component looks like, but I’m planning to move the bulk of my page layout to Flex Layout.
Optimize Change Detection
If you are coming from the AngularJS world, you are use to Angular doing all of your change detection for you. And by default, this works similarly in Angular. But, you can improve the performance of your Angular application by using OnPush change detection. This makes it so that the component will be marked for change detection when the pointers it is looking at change. This way, it doesn’t have to (for example) evaluate all of the elements in an array just to figure out if it need to redraw the component.
However, sometimes this doesn’t work. In this case, you’ll need to tell the component that it should redraw. To do this, make sure you’ve injected
ChangeDetectorRefand then call the member function
markForChange() to let the system know, this component should be updated.
I don’t know about you, but I’m loving Angular!
Other post in Angular 2
- Angular 2 – First Impressions [Compared to Angular 1] - February 25th, 2016
- Angular 2 Thoughts - October 4th, 2016
- Getting Started with Angular 2 - October 25th, 2016
- Unit Testing an Angular 2 CLI Project - November 22nd, 2016
- Adding Client Side Routing to Angular 2 - November 29th, 2016
- Angular 2 Lazy Loading - December 6th, 2016
- Reasons to use RxJS Today - December 13th, 2016
- Dissecting Angular 2 Modules - December 20th, 2016
- Awesome Angular2 Architecture Options and Opinions - December 27th, 2016
- What if Everything Was Immutable? - January 10th, 2017
- Amazing Angular2 DOM Tips, Tricks, and Warnings - January 17th, 2017
- Secrets to Styling Angular2 - January 31st, 2017
- Jedi Angular 2 Tips and Tricks - March 28th, 2017
- Unit Testing Angular(2+) with JSDOM - April 4th, 2017
- More Control with Angular Flex Layout - April 11th, 2017
- Angular(2+) Model Driven Forms Are Superior - April 18th, 2017
- Dynamically Add Components in Angular - April 25th, 2017
- How to Really use NgRX - May 2nd, 2017
- Using Real World NgRX - May 9th, 2017
- How to Really use NgRX -- Better - May 23rd, 2017
- Functional Reactive Angular Revealed - May 30th, 2017
- NgRX/Store Coding Sanity Epiphany - June 6th, 2017
- Real World RxJS Marble Testing Revealed - June 13th, 2017