I was working on a project, and during a Pull Request review someone had written a TypeScript function to capitalize the first letter of each word. I said "It looks good to me" but one of my colleagues said "Hey, why don't we use CSS for this."

"CSS can do this?" Said Jeffry, blinking surprised.

It can, and it is super simple to do. CSS provides a text-transform property.

If at all possible, I try to avoid drilling down into the ElementRef like this. I think I did it once when I created a reusable toast style component for a client, but for normal development I stick with the event directives.

This is a major update to the book text, because I finally ditched the SystemJS infrastructure I created in the Angular 2 days, in favor of the more popular Angular CLI. The Angular CLI has become a standard Angular dev tool, and the formal Angular docs and samples do not use the SystemJS approach at all anymore.

Get your updated Books here, and use the discount code LaunchDayGiftFromJeffry to get 25% off when you buy straight from us:

This worked. I actually think I like putting the styles in the main styles.scss instead of the Angular.json. I prefer to stay out of the Angular.json as much as possible.

Change Extract CSS Value

The second option, and the one in which we chose to do for this project, was to change the extractCss value from true to false. Inside your Angular.json find the value:

"extractCss":true

You'll find the value at projects.architect.build.configuration.product.extractCss

Change it to:

"extractCss":false

Now open up your package.json and find the build prod command:

"prod":"ng build"

Add the build-optimizer argument:

"prod":"ng build --build-optimizer"

This should address the issue.

When you create a normal build, the styles are minimized into a JavaScript file--styles.js--and then loaded on demand by Angular as needed. When you use extractCSS, the files are combined into a single CSS file instead of being created in a js file. Part of the minimization process seems to be screwing up the order that files are compressed, which of course affects the final CSS and why our styles were not showing up correctly.

This caused a few grumblings among my team about how borked Angular CLI is, but I still enjoy working with it.

As you probably know, I have been doing a lot of work with Angular, TypeScript, ES6, and the surrounding ecosystem. I've started using template strings a bunch.

This was the old way to create a string from many variables:

myNewValue = "http://" + myDomain + myPath + "?value=" + myValue;

It worked but got tedious. ES6 introduced something called template strings. Instead of using all those plus signs to concatenate variables, we can do use a friendly syntax:

myNewValue = `http://${myDomain}${myPath}"?value=${myValue}`;

I've read about this, done a few proof of principle samples, but for the first time I'm actually using this on a project and integrating it with code.

These are the two mistakes I make most common.

Use the Grave Accent

A template string must be enclosed in a grave accent, or backtick. This is the same key you use when formatting inline code in a StackOverflow comment or inside Slack. If you use double quotes or regular single quotes, your string will not be recognized as a template string and the variables will not turned into real actual values.

This works:

`http://${myDomain}${myPath}"?value=${myValue}`

But, this will not:

"http://${myDomain}${myPath}"?value=${myValue}"

Nor will this:

'http://${myDomain}${myPath}"?value=${myValue}'

I picked this one up the hard way after a particularly frustrating debug session wondering why all my unit tests suddenly broke.

Use Curly Brackets, not Parenthesis

The values that you inject in the string must be surrounded by curly brackets, like an object in JavaScript. For some reason my mind wants to use parenthesis, as if calling a function.

This works:

`http://${myDomain}${myPath}"?value=${myValue}`

But, this will fail miserably:

`http://$(myDomain)$(myPath)"?value=$(myValue)`

Despite these two minor roadblocks, I'm finding a lot of value in template strings because the new way of string concatenation is a lot easier to read than the old way.

Wrap Your Data Source in a MatTableDataSource: If you do not wrap your own datasource--probably an array--in the MatTableDataSource class you'll have to write your own sorting algorithm to affect your data because it won't work out of the box.

this.rowData = new MatTableDataSource(myRowDataArray);

Do this because it makes your life easier.

Tell the data source about your sort: Your MatTableDataSource does not know about the sort by default. Get a ViewChild instance to the sort in your code:

@ViewChild(MatSort) sort: MatSort;

And apply that:

ngOnInit() { this.rowData.sort = this.sort;}

Hopefully you got this far and your table is sorting now.

Write Your Own Sort: If you're avoiding using the MatTableDataSource for some reason, you'll have to write your own sort algorithm. In the HTML, listen for the matSortChange event:

I came across a question on StackOverflow about how to use Angular to restrict input to capital letters. Back in my Flex days, I'd use the restrict attribute for that, but I've never had to do that for HTML5.

I did some digging and found that HTML5 introduced a pattern attribute. I thought this is probably exactly what is needed and Angular doesn't need to get involved at all.

This is the sixth and final part in a series on Redux, a state Management Framework used with single page application frameworks such as React and Angular. This series looks at using Redux without another framework. Please read part 1, Part 2. and Part 3, and part 4, and part 5 before reading this.

This is the fifth part in a series on Redux, a state Management Framework used with single page application frameworks such as React and Angular. This series looks at using Redux without another framework. Please read part 1, Part 2. and Part 3, and part 4 before reading this.

It is functional, but over time as your application grows will become unwieldy. Each aspect of state is better handled separately with it's own actions and state modifications. To do that, we separate a single reducer into multiple reducers.

Split the Reducer

This example expands on the previous example, to show you how to split a single reducer into multiple reducers.

State objects and Reducers can get very complex in a real-world application. What do we do to make them simpler? What we're going to do is create a reducer for each section of the site and then combine them into our one big reducer function.

I created a new function named helloUser(). Notice that this function is named the same name as the state property. This is done on purpose, and you'll find out why in the next article. This function has a similar signature to the reducer. It accepts a state and an action. However, it does not accept the full state object. We'll send in the specific value for the helloUser state, which is just one branch of the main state object. This reducer function only focuses on handling its own state, not other states.

The helloUser() reducer only operates on the helloUser state variable. Notice it defaults the newState to an empty string in the command line signature. We might do something more complex if we were using an object or other data type. This reducer has to handle both major actions. If the name is modified, it sets to the new name. If we said goodbye to the user, then the helloUser resets to an empty string.

This reducer only needs to operate on the goodbyUser state. As with the helloUser reducer, and as such only needs to respond to the NAME_LEFT action. In that case, it takes the value from the action and sets it to the new state. The NAME_MODIFIED state is ignored here.

This automatically returns an object, representing the new state. The helloUser property is given the results of the helloUser() reducer. The goodbyeUser property is given the results of the goodbyeUser() reducer.