Menu

Sharing what I learn

One use of an EventEmitter in Angular.io is for a child component to tell it’s parent something of interest has happened or to put it another way; they can be used to allow data to flow out of your component.

Below is a diagram of the application which I am going to be using in this post. It shows the parent (App-Root) and the child (App-Child) components. This post will build an application so that when something (in this case a button press) occurs in the child component the parent component should know about it.

When learning about EventEmitters I found it useful to understand the component hierarchy because without it I found it easy to become disorientated and end up not knowing what component needed to emit the event and which one needed to handle it.

Create a brand new application. If you get stuck or want to look at the completed example, it is up on GitHub.

ng new eventemitter-intro

Create a new component. I am using the short cut of g c (generate component) and spec = false to omit the testing file.

ng g c child --spec=false

The final step in setting up the application is to delete all the content from the app.component.html file and replace it with:

<app-child></app-child>

At this point your new Angular App should reflect the diagram with a parent component; app-root and a child; app-child and in Visual Studio Code looks like this:

This line creates a new EventEmitter property called whichButton and is decorated with @Output(). To use the @Output decorator and the EventEmitter they are added to the import statement at the top of the file.

Next is the method that the click event on both of the buttons use. It invokes the emit method of the whichButton property.

At this point the child component now has been set up to emit an event each time one of it’s buttons is pressed. Now it’s on to the parent component to write the handler for this event.

So whenever there is a “whichButton” event emitted by app-child it will be handled by the whichButtonPressed method.

whichButton is the name of the EventEmitter property from the child component and whichButtonPressed() is the name of a method that will handle the event. This method hasn’t been written yet but will be in the next step. String interpolation will be used to display the name of the button that has been pressed.

Install Bootstrap

With the skeleton of the Angular app in place it is now time to use Node Package Manager (npm) to install Bootstrap.

From the Angular app directory that you just created run:

<<your path to >>\helloworld>npm install bootstrap

This will download the latest version, which at the time of writing was 4.2.1.

Configuring your app to use Bootstrap

Copy the relative path of the min version of Bootstrap css (Right click on the file and select copy relative path) On my PC this path was:

node_modules\bootstrap\dist\css\bootstrap.min.css

To make the Angular app aware of Bootstrap, open the file

<<your path to >>\helloworld\angular.json

now paste in the relative path of the bootstrap.min.css file, replacing the folder separator back slashes for forward slashes. so the relative path now becomes:

"node_modules/bootstrap/dist/css/bootstrap.min.css",

Note the quotations and comma, these are important and should be included. This is how this part of angular.json should now look like

Save your changes.

Testing

Normally Angular changes are immediately reflected but when making changes to the angular.json file I have noticed that you have to restart your local dev server in order for the changes to be picked up. Once done and with the your app running again using Chrome DevTools (Press F12) you can see Bootstrap is now included within your page.

Another check to ensure Bootstrap is correctly configured is to style a button so add the following button anywhere within the app.component.html file.

<button class="btn btn-danger">Don't press this!</button>

You should then see the button, styled by Bootstrap appear on your page. If not press F12 and investigate any errors displayed.

Summary

In this post I showed you how to add Bootstrap to a brand new Angular Application.

Books on Progressive Web Apps, JavaScript frameworks, Doom, a 20 year old classic and a developer life manual. Here are the technical books I read this year.

Building Progressive Web Apps

Following my attendance at NDC 2018 I wanted to find out more about Progressive Web Apps (PWA) so I started with this book.

It became apparent quite quickly that I didn’t have the vanilla JavaScript knowledge to really understand the examples and that I needed to go on a detour to improve my JavaScript knowledge and return here once I had.

The four chapters of the book that I did get through were well written.

JavaScript & JQuery

This book has been in my library since 2015 it is one of my favourite books on learning a programming language. I still return to it when I need to understand a JavaScript or JQuery “thing”.

Don’t let the page count of 600+ put you off. This is not a dense literature -esque book. The text is clear and concise and is complemented by illustrations in colour.

So after starting on the PWA book above I knew I had relearn JavaScript fundamentals so I had an enjoyable time getting back up to speed. An updated second edition of this book is eagerly awaited.

Detour

Once my JavaSript knowledge had improved I should have returned to PWA. However the podcasts I was listening to around this time had been talking about the various JavaScript frameworks used to build Single Page Applications (SPA). In the past I had ignored these because they were appearing almost one a week and stability appeared to be an issue. Now they were starting to mature, the breaking change version of Angular from JS to IO was already “old” by framework standards so I took a detour to SPA land starting with Angular.

The ng-book

I had I have already talked about this book here. Suffice to say I am not a fan.

I became so fed up with wrestling with this book, especially the chapter “How Angular Works” it put me off Angular for a while and made me switch to another SPA framework, React.

The Road to Learn React

At the time of buying this book, it had only good reviews on Amazon.co.uk. However I have now seen there is a 2 star review which although a little harsh mirrors some of my own thoughts.

Another buying signal was the 180 page count so it was not going to be another behemoth learning “X” programming language door stop. Unfortunately I didn’t get on with the format, it is A4 which means it takes a lot of desk space when the book is open and you are working through the examples and trying to see where you went wrong. There is plenty of white space on each page and I can’t see a reason why it was published at this size.

Format aside I did enjoy the authors writing style and easily got over half way through the book with little effort. React however wasn’t appealing to me and I have since returned to continue my SPA education using Angular coupled with a Udemy course.

Masters of Doom

This superb book tells the story of John’s Carmack and Romero who created id Software which after some excellent releases developed Doom which took them and their company into the stratosphere.

Although new to me, this book was originally published back in 2003 and having been a fan of First Person Shooters (FPS) since playing the shareware version of Doom on a friends 486 this book was almost as additive and I struggled to put it down and it became one of my favourite reads of any genre this year.

Software Project Survival Guide

I was reminded that I should read this book after I had listened to an episode of Seth Godin’s excellent podcast where he made reference to it.

Second hand copies are available for a bargain on Amazon and although now over 20 years old it is should be no surprise coming from the author of Code Complete that it still stands up well today. It is jam packed with sage advice that will help make running your software project a better experience for everyone involved. Some of stand out parts were the coverage of Team Dynamics, Estimating, Staged Delivery (i.e. sprints. This is in 1997!) and finally how developers should address the most difficult part of the application first.

A superb book.

Soft Skills: The software developer’s life manual

This was the last book that I managed to get in before the end of the year. I was made aware of it whilst listening to an episode of Dave Rael’s podcast Developer on Fire.

It is a difficult book to describe so I will let the rear cover do that job:…is a unique guide, offering techniques and practices for a more satisfying life as a professional software developer

With forewords by Scott Hanselman and Uncle Bob, it has high standards to keep up and it doesn’t disappoint. The book is split into seven sections covering a disparity of topics such as career, marketing yourself, learning, financial matters and physical fitness. The chapters are small which encourages you to dip in and out instead of reading the book cover to cover. The writing is engaging, in a warm friendly style that is never condescending or patronising. It is like having the mentor you always wanted by your side.

The book has been a joy to read and some of the chapters that have helped me the most were on don’t be afraid to look like an idiot and learning. In fact I am using John’s tips as I learn Angular and I am seeing results already.

It doesn’t matter if this is your first or 20th year as a developer, you will get something out of this book.

Summary

All the books I have read this year have enriched me in one way or another, yes even the ng book.

Good technical books remain a screaming bargain and one that many developers today overlook.

Virtual Box

I use Virtual Box with Windows 10 as the Guest Operating System. It is a combination that works well and other than the usual Windows update dance, it doesn’t cause me any distractions.

Visual Studio Code

All my Angular development have been built using Visual Studio Code which allows me to build, compile and run my projects without leaving the editor. I switched from Atom and I haven’t looked back. Using it is a joy and it allows me to focus on the task in hand. Superb Stuff.

Chrome DevTools

I remember the relief I felt when a friend showed me Firebug for the first time. I was having a torrid time getting to the bottom of an opaque JavaScript problem. Fortunately Tools for the Web Developer have come a long way since then and I use the Chrome DevTools every time I work with Angular; from debugging my code to inspecting elements to see what Angular has welded on to them. The things you need most are shown whilst tools you use on lesser occasions are tucked neatly away with menus that make discoverability easy.

I haven’t got any real experience of using the Firefox Developer Tools so if I am missing something useful please let me know in the comments.

Installed but not yet used: Chrome DevTools extension: Angular Augury

Angular Augury is an extension to Chrome that was recommended to me via the Udemy course I am taking. This extension is used for debugging and profiling your Angular Application. I haven’t had to use it yet so will revisit this post once I have some real world experience of using it.

Err. That’s it. How does your development environment differ? What am I missing?

I have spent many months this year learning Angular. More accurately I have wrestled with Angular, left to try React then decided that to get the most out of learning these frameworks I need to brush up on my vanilla JavaScript skills which I proceeded to do before finally returning to Angular. Phew!

I have used several resources to get up to speed with Angular and what I found useful and others that were not so are listed here. At the end of the post I ask for resources that have helped you learn Angular so if you don’t get that far please leave your recommendations in the comments

The good: Udemy Course

A friend recommended the Udemy course Angular – The Complete Guide by Maximilian Schwarzmüller. At the time of writing I am about half way through and it is the most enjoyable Angular resource I have found. Max is a friendly, enthusiastic teacher and the course is highly polished and easy to follow along building the sample applications and experimenting.

In addition to the discussions around language features there are lots of useful nuggets such as how to understand the opaque Angular errors that you are bound to see in your early days with the framework and the use of the browser add in Augury which is a very useful tool for debugging and profiling Angular applications.

The bad: ng-book

I have only purchased one book on Angular which was the eBook edition of the ng-book The print version was not available at the time. This is a large book running to 650+ pages. I didn’t enjoy it and only got as far as chapter 3 before giving up. Not sure why I didn’t enjoy it, perhaps I didn’t like the style or the fact that I prefer printed books? I lost patience by chapter three as the app wouldn’t work and I had no idea why.

If you have a recommendation for an Angular book please do get in touch.

The ugly: Official Docs

My adventures with Angular started with the Angular home page, I built the Tour of Heroes sample application and have wandered through the rest of the documentation look for other stuff to try out.

I have found the documentation to be dry and not a place that rewards you for spending much time there and so far I have had little reason to return. Problems that I encounter normally result in a Google search followed by a visit to the StackOverflow question.

Perhaps as my experience with the framework grows and I need to look things up I will be spending more time with the docs. If my opinion changes I will ensure that I update this post.

Help needed

If you have Angular resources that you think may help me no matter how small please leave a comment.

The problem

The output from running this in Chrome 67 is that the array is now sorted as:

[1, 11, 2]

Which is not what we want, the number 11 is in the wrong place.

The Reason

This result is produced because using the JavaScript sort() without a compare method array causes elements to be sorted by converting them to strings and comparing strings in Unicode code point order.

Apologies! That was a bit opaque so lets take that last paragraph apart. The sort method first converts the numbers to strings so we conceptually have

“2”, “1”, “11”

The UTF-16 code for each of these are obtained and these are respectively

0032, 0031, 0031 0031

With both “1” and “11” having a lower UTF-16 code than “2” it should now be slightly clearer why 11 appears before 2.

The Solution

The sort method compares two values to determine which should come first. These two values are usually referred to as a and b. The sort method can have an function, anonymous or named as a parameter. This function is a referred to as a compare function. The compare function allows you as the developer to define the rules for sorting.

The compare function should return a number. That number will be used to determine which of a or b comes first.

<0

If the compare function returns less than zero a should be shown before b

0

If the compare function returns zero, the a and b should remain in the same order

>0

If the compare function returns greater than zero b should be shown before a

Shown below is an example of anonymous compare function:

function(a, b) {
return a - b;
}

This function can then be passed to the sort() method as shown below. The calls to console.log are instrumentation that you can use to see what is going during each of the three times the compare function is invoked.

Pasting this into the Chrome console window will produce the following output:

Stepping through the output, first displayed is the array in it’s original order.

The next two lines shows the results of the compare function and in this invocation the parameters a and b have the values 2 and 1 respectively

2 – 1 = 1 means that the compare function returns a number greater than 0 so that 1(b)will be shown before 2 (a)

The next line shows that the a and b values for the final invocation are now 2 and 11. 2 – 11 = -9 which means that the compare function this time return a number less than zero so that 2(a) will be displayed before 11(b)

The final line shows the results of the sort and now the numbers are sorted as expected.

Here’s what I learnt when building two To Do applications. One was built using pure JavaScript and the other used jQuery with a smidgen of JavaScript.

Each To Do list had to satisfy several basic functions. The user had to be able to add tasks, remove tasks, save tasks and be able to retrieve them. These To Do lists are far from production quality but what I have learnt by building them will help immeasurably in my next project and the one after that and so on.

Tools

Both examples were built using Visual Studio Code, jQuery 3.3.1 and Chrome 67. Any text editor can be used instead of Visual Studio Code but I have found it to be a joy to use and is now a firm favourite of mine.

Understanding Immediately Invoked Function Expression or IIFE. Whilst there are other reasons to use an IFFE such stopping name collisions in this example I have used an IFFE to call a function that retrieves the saved tasks once the Document Object Model (DOM) has been loaded.

Although there is only 200 lines of JavaScript I have become familiar and thankful for Chrome Devtools. Pressing F12 has become second nature when I need to find out what is actually going on with my code. From seeing errors shown in the console to adding breakpoints via sources, I have found Chome Devtools so intuitive to use.

Creating and removing input items dynamically. The To Do list needed functionality whereby a user could add and remove tasks which translated to being able to create input elements and attach them to the parent. When removing an item, the code needed to find out which task had been selected for removal before removing it.

When refreshing my knowledge of JavaScript I was having trouble getting to grips with which selector I should use when selecting elements of the DOM. Experimenting with different JavaScript selectors such as querySelector, getElementById for single element node selection and getElementsByName for selecting more than one node gave me a greater understanding of working with the DOM and the difference between the code required to handle one node compared to when a node list is returned.

Use of the jQuery ready method. All the code used by index.js is contained within the jQuery’s ready method, the shorthand version of which is shown below

$(function() {
all code goes between the opening and closing brackets
}

Doing this ensures that the DOM has tree has been constructed by the browser.

Similar to the JavaScript version I learnt how to create and remove items dynamically and attaching or detaching them from the parent as necessary.

When working with items using the id attribute requires use of the # symbol followed by the unique name. e.g. to select the following element:

0 tasks

The following jQuery expression is used

$('#Count').text($countOfItems);

Refactoring. As I was building this second ToDo list I could see ways to improve and do things better with less code. In addition whilst working on this version I discovered a bug with that would have also affected the JavaScript version as well so I was able to go back and fix it in both.

I really enjoyed working with jQuery and love the simplicity of selecting items and then chaining of actions to do interesting work with the selection but there were times that I thought pure JavaScript was a better fit. Within index.js you can see the function getLocalStorageAsArray() does not use jQuery.

Use of .each(). jQuery allows you to update all of the elements selected without the need for a loop. However there were times when I needed to perform some actions on each element found by a selection which meant use of the .each() method which allows you to recreate a loop in scenarios when it is required. This required a slight shift in thinking because it is too easy to think a loop is required (coming from another language) when a jQuery selection is all that is really needed.

A pleasant side effect of working with .each() was that I needed to find out which iterator my .each() was currently processing and during my hunt for an answered discovered that the jQuery official documentation is really good and it succinctly pointed me to using using the index argument.

The number of lines of code when using jQuery versus pure JavaScript reduced the lines of code by about 50 lines (I’m in no doubt a more experienced developer could reduce both versions down even further.) I am not going to read too much into that because it is like comparing apples with oranges but for me it was an interesting observation.

Summary

I have surprised myself with how much I have learnt building these and how much fun I had doing so.