Stephen Adams

Why you should allow developers to write tests for existing code

Is it possible to add Unit Tests to an existing application and if you do decide to add tests to a project, what benefit will this have to an existing application?

I’ve worked on a few projects where the application has been started, the first few features of the app come to life and before the developers realise the application is nearly delivered to the end user, without any Unit Test coverage.
One of the main reasons for this is when an application is started there is usually a tight deadline, or a push to get something out to the end user within the first sprint and there isn’t time considered for the writing of tests. The unit test theory is that a test should be written before any code is written, but with time pressures writing tests is always something ‘we can do later’.

But can unit tests be added to existing code? And what benefit will this bring?

It is possible to write tests for existing code, it is, in fact, a good practice to go through this process for a number of reasons.

It provides confidence that new changes do not break what is already there

First, it stabilises the codebase of the application, providing confidence that any further changes are not going to break the existing code. Once tests have been written for the existing code, developers know that there is a quick way to check if the new feature they are adding is not breaking what is there already. As they go through developing this new feature having the test runner going in the background running all the tests the developer will see straight away if the change they are making is stopping existing code from working as it did before. They will get a red warning, telling them exactly what is no longer work and why.

It highlights areas to developers where code can be improved

The second reason is when writing tests for existing code developers will notice areas where the code can be improved, optimised. When writing a test you need to know exactly what the code you are testing is doing and how it works. Through this investigation, developers will see ways it can be refactored to make improvements. Once this code has been refactored and improved the test will ensure that any further changes don’t break this improved codebase.

Its a great way to onboard new developers to a team

Another reason that allowing your developers to write tests on existing code is it is an excellent way for new developers to a project really understand how an application works. If for example, you have a large enterprise business application, that has many business rules. It can take a new developer to the team to both understand the business rules, but also understand how the application currently supports these rules. If for their first few weeks on a project they are given the task to write the tests for a certain section of the application, maybe an API the application provides or a set of services that the application uses to process user orders. Through writing tests, the new team member will learn, in depth, how the current application works. They will also be involved in how the application is built, deployed, how the processes the team has for committing code, what rules there are in place for writing code. All this they can do through writing tests without affecting the code of the application.

How can tests be added to your existing project?

If you are a project manager or the business owner of an application and your team have said that the Unit Test coverage for the application needs to be improved. There are some things you can do to help this.

Writing tests should be defined as Sprint stories

You don’t need to stop development on new features just to have your team write all the unit tests for the application. This can still continue, but you need to add time to each sprint (if that’s the method you use) to allow the developers time to write tests for part of the application. When it comes to sprint planning have a few stories for writing tests. Prioritise areas of the application where test coverage is low, maybe focus on areas that are more stable, an existing API for example or the data model which isn’t going to change for a while. Assign these write tests user stories to the newer members of the team, so all they can go through all the development processes the team uses.

Improving test coverage can be a gradual process

The existing application doesn’t need to have 100% code coverage straight away. It’s better to add tests gradually as the project progresses, tests can be bought in for existing code. This does mean there is a risk that changes could break another piece of existing code, but if the tests are being written this risk will get less and less the more coverage your application has.

Allow your developers to write tests

When you are planning some work with the team, a new feature to be added. Allow time in estimates for the developers to write tests. If this time is not in the estimates developers will find that they don’t have enough time to not only write the new feature and write the tests. So the tests will start to be left, this will cause the test coverage to reduce over time and you’ll be back to where you were before, with an application that has a lot of functionality and existing code, that isn’t covered by tests.

Your QA team and clients will thank you

Finally, an application that has a higher test coverage, will have fewer bugs. New features won’t cause new bugs to appear in the existing application.
This makes the QA team happy, for them it means that they can be confident that what is already in the application still works as before. They don’t need to thoroughly test the entire application every time there is a release. They can quickly test the existing application and then focus on testing the new features. Any bugs that crop up should be caught by the developers during the development phase when they have their test runner quietly running along as they write code and then warning them as soon as any issues come up. Instead of the QA team raising a new bug.
Having the QA team raise these minor bugs which could have been caught by unit tests, takes time. It adds delays to the latest release of the code being allowed out to the end user.
So if your end users are waiting for a new feature that will greatly improve their experience of an application and this new feature is delayed due to the release not getting past QA because they have to raise a bug for something that has broken in an existing part of the application. The end user will be disappointed, and a happy end user is what we all want.

Unit test coverage is important, it vastly improves the quality of an application, but if due to time constraints an application has been delivered without a high level of test coverage, it’s not the end of the world. By allowing developers to write tests for the existing code, the coverage will grow over time and the quality of the application can be guaranteed when a new feature is released to your happy users.

Writing good Pull Request descriptions

As developers, we like to get work done quickly. There is a feeling that if we finish fixing an issue or completing an issue as quickly as we can, then is obvious to the other team members, who may not be developers, that we are good at what we do because we get things done quickly.
This is dangerous, it can lead to bad practices slipping into your teams’ processes, where developers are trying to cut corners and get that Pull Request (where a developer asks the rest of the team to ‘pull’ their code into the main codebase of an app) ready as soon as possible.
One area where this cutting corners can happen is in PR (Pull Request) description messages, where the developer explains what this PR is about. If this is not completed then all the other member of the team who is reviewing the PR (where a second developer looks at the code changes made, and checks for any problems or can suggest ways that something might be done in a more efficient way), this second developer will just be shown a list of files, with the code changes highlighted.
From that, they need to work out what this PR is trying to either fix or add to the app’s codebase. Usually, without this context, the second developer will look at the changes, and think ‘well the syntax of the code looks fine, there are no obvious problems with how it’s written, I’ll Approve it’. Then this new PR is added to your app’s codebase, it all works and everything is fine.
But a few weeks later your users are complaining that the app has a strange issue when they use it. So you ask your developers to look into the cause of the problem. It could be due to something that has gone in the latest version of the app. So as any good developer should, they look through all the PR’s that went into that last release of the app.
This is where having a good description of what was done for a PR is so important. Yes, you can find a branch number that matches the list of the branches of code that went into a release, but if there is no description or no context of what work was completed as part of the PR, then it all becomes a guessing game.

So what goes into a good description?

There are a couple of things I think should go in a PR description:
1. Ticket number and title
2. A brief explanation of work completed
3. Bullet list of changes made

Adding a Ticket Number and Title

The title of a PR can have a lot of different variations, I’ve seen some places where the title is used to show a log of the changes made. From the PR’s in a release a log showing all the titles was used to show a report of what went into a release. This is helpful, but it meant that all the PR titles needed to be in a certain format and this format wasn’t particularly reading for humans.
Having the title of the ticket and the title number in the description as the first line makes it possible for a developer to see what was the corresponding ticket (if we’re using Jira) and what the name of the ticket was. Then the developer can search for that ticket and get an overview of what the PR was trying to do.

A brief explanation of work carried out

Next, I would add a brief, a few paragraphs, not an essay, an explanation of what work was carried out, what was added or fixed and how this was done. So someone could read this and get a sense of what was completed in the PR.
This doesn’t have to be too much, just enough so anyone knows what work was carried out.
A description is not only useful to other developers who may have to work on an old PR but also the original developer, to remind them of what they did for the PR.

Bullet list of changes

This is where you just list the changes you made. Maybe list each amended or new file and list what changes were made. Something like:

Add new sort function to account service
Removed commented out code from the interface
Add unit test for main login service

Along with the title, brief description and bullet list of changes it is clear what went into a PR. Making it easier for developers in a team to be able to see what went into a PR.

Some developers in your team might say that this is a was of time, and if you need an explanation of what some code does then it’s not well-written code, but I think that’s laziness on the developers’ side. No one’s code is that easy to read, especially after a few months. Having your developers follow the good practice of adding a description to any PR they make will no doubt help the team. The more the team know what’s been added to the code base the quicker a fix for an issue with an app can be fixed, the faster the fixed app can be released to your users.

If your team aren’t using descriptions in their Pull Request’s then maybe its time to ask them why, and if they say it takes to long then make sure this effort is included in the estimates they give. It’s work the time in the long run.

Principles of Writing Testable code

I’ve recently been spending time researching into how to write unit tests for an existing codebase. One thing that keeps coming up in the research I’m doing is how important it is to write testable code from the start, but what is testable code?

Well from the research I’ve been doing I found that to write testable code a good approach is following the SOLID principles.

S – Single Responsibility Principle
O – Open/Close Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

So what do these principles mean and how do they apply to Angular?

Single Responsibility Principle is where an Object should do one thing and one thing only. For example in a controller or component you might have a function that loads some data, updates a local array then loads some more data from another source and finally displays this data in the UI. Well, that is four different things this one function is doing. To make this more testable it would be better to have one function that loads and returns data. One function that binds data passed into it to a local array, then another function which loads data from the second source and then finally allowing Angulars data binding to bind the data to the UI.

This means that you have only three separate functions, which can all be tested separately. One test to check the first function loads data correctly, a second test to check that the second function binds any data passed into it to the local array and finally the third test to check that the third function loads the data from the second source as expected.

Open/Close Principle is where a class is Open to extension, but Closed to changed. An example could be a function loads and returns some data. Then as the project continues the requirement for that data is changed as it is now ordered alphabetically. So you go back and amend the function to order the returned data after it has loaded. By doing this you’ve broken this principle. What you should really do it add a new function that calls the first function, then takes the returned data and then the second function performs the ordering of the returned data. This way you have two separate functions, both performing smaller tasks and the first function, which is already tested, has not been changed.

To write a function with this principle in mind, it needs to (in this loading data example) be able to return the loaded data and not just simply bind the returned data to a local variable or array. If the load data function returns the data as it loads it, then this allows other functions to take this returned data and extend what can be done with it.

Liskov Substitution Principle is where a class that uses another class, should be able to accept using another class without it knowing the difference. Within Angular, this means a controller or component may be using a service to load data, but the controller/component knows so little about the service that another service could replace the original one, without any changes needed to the controller/component.

This is an extremely important principle for writing testable code because adhering to this means that external services can be mocked in tests in order to write tests for just the function that uses this service. Through the use of mocking we can write tests that test different scenarios to see how our original function handles various responses from the mocked service.

Interface Segregation Principle this is important because it forces you to write smaller interfaces/classes which are easier to mock in tests. For example having a service that does loading data, aggregating data and ordering data, means that you will need to mock all three different functions in order to test something that is just using the loading data function. Separating it into three separate services means it is easy to mock just the one you need in order to test your code.

Dependency Inversion Principle is where your concretions (the act or process of concreting or becoming substantial; coalescence; solidification) or classes that are set out. Should only depend on classes that are abstractions of functionality. This means if you have a class that does something, like filtering an array. Then anything other classes it needs in order to perform this filtering should be an abstraction of the implementation. For example, with your class/function that filters an array, you may use something like Underscore or Lodash to help with the filtering. When you use Underscore or Lodash’s function you aren’t using the inner workings of the library, but an exposed function that abstracts away the inner workings of the library. So if in a new version of the library the helper function you are using is re-written to make it faster, as far as you are concerned you are still calling the helper function in the same way.

So by writing your code using this principle, you are writing more loosely coupled code, which is easier to test, because you test the individual parts. Parts that know nothing or need to know nothing about the inner workings of each other. This makes mocking for tests easier to do.

Following these principles will help make your code more modular, separated and therefore easier to mock for the tests you are going to write. From the research I’ve been doing the main concept to get in order to write more testable code is, in isolation, meaning writing code that can run in isolation is easier to test. It is easier to mock any dependencies (which there shouldn’t be many) it’s easier to write tests just for that single piece of code. Therefore writing more and more tests leads to an application which has more test coverage going forward.

Here are some links to articles, blog posts I’ve found during my research:

Theory of Uniting Testing in Angular

I recently finished reading through an article on Unit Testing in Angular. The article was from the Infragistics website and in 3 parts it tried to demystify Unit Tests in Angular:

In this article, the author, Jared Fineman, really goes into how to setup your tests, how to structure tests and some of the great new features of Angular, that help with testing. One great point Jared makes is *In the world of development, unit tests have long been viewed as second-class citizens. * This is very true, it is something I have been guilty of too, forgetting that Unit Tests are an extremely important part of the development process. As part of my drive this year to improve the quality of my work, I’m focusing on both Unit Testing and readability, so I need to make writing test a core part of my development process.

In the first part of the article, Jared shows how to set up tests for your project. Though at the time of writing this version 6 of Angular was not released yet. So there is a section about updating the .angular-cli.json file, which has now been replaced by the angular.json file. Then in the other two parts of the article, Jared goes through structuring unit tests and some of the great features that Angular has that allow you to really explore the inner workings of your components. So you can write tests that examine all parts of the component.

The one that struck me in the second part of this article was the approach he mentions for structuring your unit tests. He mentions this AAA approach, which stands for Arrange, Act and Assert. The idea is that you first setup everything needed to run the component that is going to be tested, you basically arrange all the parts needed for the component. This could be modules that need to initialised, other parent components or mock data.
Next is the Act section, this is where you call the method or the component to be tested and from that call, the result can be examined. Finally, there is the Assert phase, where our assertions or expectations are tested.

This AAA methodology is great for learning how to set up tests, it is definitely something that isn’t documented enough in the official Angular docs. If a developer is new to Angular and they want to start writing tests for their app, the Angular docs do give a detailed overview of how to write a test for different scenarios. The new Angular docs really give a lot of examples, how to test components, how to test the DOM, how to test services and providers, but the theory of unit testing is not discussed enough in the documentation (but the Angular docs is open source, so maybe that can be changed).

There is, of course, articles about AAA outside of Angular, here are a few I found, though they are C# based the theory still applies:

There are a lot of articles about the Theory of Unit Testing, just not all Angular specific. It is worth searching around for them. This article from Jared Fineman is a great start.

When enough is enough,

There is a time when writing code that you need to say to yourself, enough is enough. I’m not talking about giving up coding, what I’m talking about is when you’ve been adding so many features to a section, that the code is unmanageable. There is a point where cramming in another feature to a section, means that the code behind will need to be re-written in order to make it easier to read, easier to manage and easier to test.

One of the big problems with AnglarJS, when it first became popular was developers didn’t know the best practices for how to write good clean AngularJS applications. The main problem was with the controller. The controller is a great concept, having a JavaScript file that sits behind your HTML template, which has access to all the elements in the template was amazing, but soon developers started to go crazy writing everything in one controller, at the time there wasn’t a ‘style guide’ that showed us a better way. Slowly over time, better practices were shared in the community, there were more examples of how to structure our AngularJS apps.

Recently I’ve had to work with an AngularJS project that has a controller where the structure of the controller has become unmanageable. Currently, the file has over 1200 lines of code, it is full of functions all doing different things, nothing grouped together in a logical structure, the use of both $scope and VM models is throughout the file instead of using one approach consistently. It is hard to work with this controller, and it is important of the functionality of the application.

Now I can see how this controller has gotten into this situation. It’s clear that at the beginning of the development this core piece of functionality that the controller manages was not fully planned. So the developer probably thought, this section doesn’t have a great deal of functionality I can keep it all within one controller.
Soon the features for this section grew and became more and more complex, the demand to get them delivered also grew, so the time for refactoring was not available. Now we are in a situation when we have a 1200 line controller that is hard to work with, nearly impossible to add new features too and is still buggy.

In order to stop this type of situation, developers need to be able to say to the PMs and stakeholders of a project, that they need to spend some time, refactoring the existing code in order to make it so new features can be added easily.

When a team successfully uses Scrum there is this time to raise issues like this, to let the PMs know that a bit of time is needed in order to tidy up the code before tackling a new feature. As part of the standard sprint planning, this can be raised. Without it the team just keep ploughing on building onto of existing code, adding feature after feature until everything is nearly unmanageable.

So what can developers and teams do in order to stop this happening:

Have regular sprint planning meetings to discuss the work coming up and not keep ploughing along without reviewing
Set out from the beginning a style guide, how the team will approach the development of the application
In PR reviews, don’t just have a quick look over the code and accept it, discuss with the developer if there are problems or code smells and how they can restructure their code to avoid these types issues later
Teach the more junior developers good practices on structuring code
Tell the managers and stakeholders why having good code quality is important to their project, why cutting corners, will only come back to haunt a project later on

Unit Testing and tight timescales

I’ve worked on a number of projects, where we’ve started the project with the idea to have 100% coverage with unit tests, but as soon as deadlines start to get closer, unit tests are the first to go.

What are the reasons for this?

There are several reasons why this happens, as the deadline for a project gets closer, you’re developers are put under more pressure to get all the features completed. So they need to focus on that, the time spent on updating or creating new Unit Tests is then spent on getting these features delivered.

If the project being developed in an internal project, and the stakeholder sees that the release deadline is getting closer, they are probably wondering why their developers are spending time writing tests and not being that new feature they have just asked for. I’ve seen this several times, the project manager or business owner, is under pressure to deliver and they hear a lot of talk from developers saying they need to write the tests for a feature, but to the PM that seems a waste of time. On one project we were asked to stop developing unit tests as we needed to get a version of the website ‘out the door’.

I’ve also been on projects where, as a team, it was decided to ‘come back and write the tests later’. As an approach to getting this high level of quality that the project needed. This wasn’t a good idea, as we never went back to write the tests and eventually the code coverage on the project was very poor.

Unit tests and test coverage are sometimes seen as nice things to have. We know as good developers we should have them, we should have tests for every line of code we write. There are many talks, books, podcasts, where ‘experts’ are telling us, developers, that you should be writing tests. It’s like when you are trying to eat healthily, you know you should make a salad for lunch, but those crisps and cheese rolls are just so much easier and quicker to make.

How can this problem be solved?

The central cause of this problem is time, projects basically run out of time to get all the features of a project completed and still write the tests. One solution to this problem is better planning up front. When scoping out a feature, developers need to see unit testing as an integral part of the development process. If they are using the points system in scrum to say what the effort involved in creating a new feature. Writing the unit tests needs to be considered as part of this effort and it is up to the senior members of the team to remind all the developers to include this unit test development as part of their estimates of effort.

Developers need to also show the Project Managers and stakeholders the importance of maintaining good test coverage is to not only to the project as it is now, but a year or two down the line, when a new feature of the site/app is going to be added to the project. When these new changes start to be developed for the project, the PM/stakeholder needs to know how important it is to have good tests during this ‘adding a new feature’ development phase is, in order to make sure the existing site/app doesn’t have bugs introduced.

As well as developers not adding the effort required to their scrum estimates, and PMs not aware of the importance of keeping tests up to date in a project, another issue is that writing test does take a long time, especially if you are just starting out writing tests. I’ve worked on projects where when I was writing my unit tests I wasn’t convinced that the tests I was writing were actually ‘testing’ my code, but was probably just checking that a value is present. The quality of the tests was not very good..

As developers, we are shown all about the features of a new framework or library, how it does the new latest thing, how fast it runs and how it is better than framework X, but it is very little in the framework documentation on how to plan your tests? What approach should developers take when writing tests? We see many examples where a test suite is set up, and the test checks the value of a <span> in a template, or a test for an HTTP request of a static file, but there isn’t much information about the ‘theory’ of writing good unit tests. Have you tried writing tests for AngularJS directives? It’s easy to check the HTML of a directive, but testing the inner workings of your directive? Nearly impossible.

If developers spend the time learning about writing tests, and if the authors of these frameworks/libraries show others how to write good tests for their framework based apps. The time developers spend writing tests will be reduced. The more we practice something, the quicker and better we get.

If PMs and stakeholders can see unit tests and coverage as an investment into ensuring the quality of a project and the providing long-term support to a project, they will allow the developers to spend this extra time need to write tests.

Job hunting as a Contractor in todays world

I’ve been contracting now for nearly six years (it’ll be six years in July) and ever since I started I’ve been constantly going from one contract to the next. I’ve been lucky enough to only have one short spell of about 3 weeks where I didn’t have a contractor was waiting for one to start.

Does this mean I’m the best contractor out there or the most gifted Angular developer in the UK with companies just queuing to offer me the next contract? Well no, unfortunately, that’s not true. I’m a good Angular developer but I’m not Todd Motto.

What I have been, is good at job hunting.

I get most of my contracts through recruitment agencies, love them or hate them, you can’t live without them as a contractor. This means I speak to a lot of recruiters on the phone. The conversation usually goes something like this. ‘I have a role, it’s for a company in London, doing Web Development. They also have pizza and snacks. Now tell me everything about your last role’.
So what this translates to is, ‘we have a role, which you could be one of many CV’s I put forward. It’s actually in South West London, so that’s an extra 40 min tube journey for you, but we all know you developers love pizza. So you should be happy there as once or twice they have provided pizza (but you’ll have to work all night to get it). What I really want is the details of your last client so I can contact them and try to sell my recruiting services to them’.

So there are a lot of missing details here, where exactly is the role (if you have a 30 min train journey into London, another 40 min tube journey all adds up, are you prepared for that amount of travelling), what are they looking for, what skills is the client looking for. If the client wants a Java developer, but you’ve only used JavaScript, then it’s not a role for you. What is the day rate? This is extremely important to find out early, but it is a tricky part of the initial conversation with the agency.

The client must have a budget of how much they are will to pay a contractor, the agency takes a percentage of this day rate for their services, which is fine. You as a contractor are also running a business, your own limited company. This limited company comes with all the taxes and costs that any other business has. So you need to bring in enough money to cover those costs.

So there are 3 separate companies trying to make the best of a set budget. As a contractor, you need to think about your business needs first. This is why we have an ideal day rate, but the topic of day rates and setting them is something for another post. Back to the process of finding work as a contractor.

When I started contracting, all you really needed was a good CV and a phone. You’d upload your CV to JobServe, apply for a couple of contracts and the phone would soon start ringing. Then you have to speak to the agents, telling them what you’ve done before, how many years experience you have in a certain technology (which is never a good marker for technical knowledge, but its all they have) and what your availability for interviews is. That’s it, your CV went off to the client and if they wanted to see you, the agent would happily arrange it.

That’s how it was a few years ago, but like everything else related to the web, things have changed, fast. Now it is no longer enough to have a CV listing a few technologies and your recent 5 jobs. Clients want to know more, they want to see more about you as a developer. Thanks to sites like GitHub and BitBucket you can create your own portfolio of code. Your GitHub account is a window into seeing what type of developer you are, the type of projects you’re interested in, how you write your code, the way you structure your code. All this can be learnt through having a good Github account.

But does this mean without a GitHub account or one with a bar of green squares, you’re not a good developer? If you don’t spend all your waking hours committing code, does that mean you don’t know as much as someone who does? Well no, but for a recruitment agency it is all about numbers, the number of years you’ve been using a certain technology, the number of projects you have in GitHub, it’s all the same.

So as I said, in July it’ll be six years since I started contracting and now how I have to find jobs has changed. I know I have a good CV, it’s up to date, not to much waffle, it doesn’t just list technologies I’ve used. I’ve tried to describe the types of the projects I’ve worked on, what I did in these projects, but I know that I need to do more to promote myself as a developer.

I do need to add more to my GitHub account, show more of the code I write, I should get involved in open source, there are many benefits to working with open source for contracting developers. This is another great topic for a blog post.

The things to remember as a contractor when it comes to job hunting are:

– Have an up to date CV that you can send out quickly.
– Be able to talk/communicate well with recruiters, they are extremely helpful.
– Keep promoting yourself, your skill set, experience.
– Keep an eye on the job market, even if you are in a long-term contract. That way you know the current market rates, what people are looking for.
– Try to find out as much as you can from the agency, ask them loads of questions. The more you can learn, the more you’ll be sure the role is for you.

Interesting issue with Angular Material

I was recently starting a new Angular/Angular Material app, using the latest version of the CLI. Following along with the getting started guide I created my basic app, but as soon as I added a Material component I was getting errors that were stopping my app from running.

The error I was getting was:

node_modules/@angular/material/slide-toggle/typings/slide-toggle.d.ts(55,18): error TS2315: Type ‘ElementRef’ is not generic.

This is a strange and slightly misleading error. After a bit of digging around, I found a GitHub post where someone mentioned that if in your package.json file the version you have of Material is 6, but your version of Angular is 5 then this error is thrown.

Now, this is a simple issue to fix, thanks to the new ng update feature, all you need to do is run ng update and all the angular versions are up to 6. Rebuild your app and run ng serve and the app runs perfectly again.

This was a strange issue that I spent a little time looking into, but it does show how useful ng update is.

Material Starter Components, the hidden gem of Angular 6

Angular 6 was released just a few days ago and with it came a whole set of features, including Angular Elements, being able to update your app to use all the latest packages using the new ng update feature. There is also ng add which allows you to add new packages to your app using your chosen package manager, either npm or yarn (or whatever new one comes out in the next 6 months).

After reading through the new release blog post, one set of features that haven’t been getting as much exposure as say Angular Elements, was the new Material Starter Components, which are part of this release.

I like Angular Material, I think it gives a great polish to the UI. When I’m creating Angular apps having the UI handled by a library like Material or ng-bootstrap, really helped to get the development of the app moving quickly. So I was happy to see that in Angular 6 there are these Starter Components.

But what are these components, well they are just standard Material components that generate layouts for your app. If you’re building an app that requires a collapsible side nav, there is a new component that will generate that for you. Not just the Nav but the main container and the side navigation with a couple of demo links so you can quickly get started building upon the basic structure the component generates for you.

There is also a dashboard component, which generates a layout of a dashboard application with a section for various panels that the dashboard would use to display information in. Again this can be generated using the standard ng generate command of the Angular Cli.

What I find really exciting about these Starter Components is that they can be built by teams who want to have their own layouts and share them with the Angular community. If you’re building an HR app in Angular and you need a layout for showing staff details, check to see if one has been built by someone in the community. If it’s there then all you need is one simple command in the CLI and you have the basic layout of your app generated for you ready to go.

The more of these Starter Components there are, the easier it will be for teams to get started building responsive, attractive looking UIs with Angular Material.

For further information of Material Starter Components, there is the official docs on Schematics, the functionality in the CLI that allows you to add Starter Components. There is also a video by Tina Gao who works on the Angular Material team, where she discusses the Material Tree component

Why Angular Developers Love NgRx

If you saw any of the recent talks from ngConf, you will probably have seen one on NgRx, it was a huge topic at the conference this year, but why are Angular developers all talking about NgRx?

If you run a team of Angular developers they probably have already mentioned that they are looking to use NgRx in a project sometime soon, why? Well because NgRx solves one large problem, state management. What is state management, well it is a way of managing the state of an application between screens For example if you have a six-step process that needs to add to the application your team is building. In order to pass the information enter in step 1 to step 6, state management gives the developer a way of storing all the information added throughout each step, so it is accessible throughout the entire processes.

Before state management libraries like NgRx, developers use to have different approaches to store the state of the application, from storing all the information in local storage in the browser to cookies and even writing back to a temporary table in a database. With each project, there was probably another way of managing the state of the application.

This means when your developers are working on a project there wasn’t a common approach to the state management problem, but now thankfully due to libraries like NgRx, there is.

Another great feature of libraries like NgRx is the dev tools that come with the library. These ‘dev tools’ are features written into the library that take advantage of the wonderful features of a modern browser, by tapping into the tools the browser gives. Tools that allow the developer to really look into what is happening in the application as it runs. NgRx comes with a feature called store devtools this gives the developers the ability to add or amend the state of the application to see how the app handles different states. This is something that was usually done in the QA stage because it was easier to set up in QA. Now a developer can change the state through their browser to see how the app behaves. The better a developer can test how the app behaves at development time, the fewer bugs, the less time an app spend going through the QA process.

So to recap, Angular developers are loving NgRx at the moment, for two main reasons. One it gives them a standardised way to solve the problem of state management within an application, and two it helps provide fantastic tooling for developers to really look into how the application is working.

But NgRx isn’t the only state management library available, there is also NGXS which is another state management library for Angular. This one takes the approach to be more class-based, thanks to classes in TypeScript, than NgRx, which is more function based. Both tackle the same problem of state management, but NGXS has taken what people have learnt from using NgRx and implemented an approach that uses the great features of TypeScript.

If your team are looking at NgRx it is worth adding to your project, it will help your team with providing a common approach to one of the trickiest parts of building a modern web application.