Getting Started

There are a few things that we will do at the beginning of every application build, these are things like:

• Generating the application
• Enabling TypeScript strict mode
• Installing packages
• Restructuring the generated application to our liking

For this first application build, we will explain each of these steps in a little detail. However, we will also be performing (more or less) the same steps for every future application. We will just explain it in detail this once, and then in the future applications we will just go through the motions of setting it up. The idea is that this lesson will get all of the boring set up stuff out of the way so that we can jump into the more interesting aspects when we start coding properly.

Generate the Application

Generate a new application with the following command:

ionic start quicklists blank --type angular

Open the project in VS Code or your favourite editor

With the project created, we are going to make a few modifications to get it to our liking. Well… my liking specifically, you are welcome to set things up however you like. If you don’t already have established opinions of your own, it will probably be best for you to follow along with the approach I use.

Enable TypeScript Strict Mode

This is something that is enabled by default in standard Angular applications, but in an Ionic application TypeScript strict mode is disabled by default.

Turn on strict mode by adding strict: true to the compilerOptions in your tsconfig.json file:

  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "declaration": false,
    "downlevelIteration": true,
    "experimentalDecorators": true,
    "moduleResolution": "node",
    "importHelpers": true,
    "target": "es2020",
    "module": "es2020",
    "lib": ["es2018", "dom"],
    "strict": true
  },

We already have some sense of what the role of TypeScript is from our basics section. In some sense, you can kind of think of the TypeScript compiler as sort of being like an automatic code reviewer checking your code and making sure what you are doing is safe and makes sense (at least in terms of how data types are being used).

Turning on strict for TypeScript sort of takes the TypeScript compiler from being like a friendly coworker pointing out when things are obviously wrong with your code, to a strict micro manager that will pick up on every little potential mistake in your code. That might not sound all that appealing, the TypeScript compiler is going to be complaining about a lot more and it is going to force you to deal with issues you might not have had to before.

However, the things it is going to complain about are things that could potentially cause bugs or issues that you might not realise without it. You will mostly notice differences with this mode when something might be undefined or null. For example, when we build this application we will create the following input for one of our components:

@Input() checklists: Checklist[];

Except, we won’t do exactly this. In Angular, the @Input properties are not set immediately. So, even if we do always pass in a checklists input to this component, there is a brief period of time where this.checklists on this component will be undefined. This is fine with the non-strict TypeScript compiler, but it makes the strict TypeScript compiler quite upset.

Instead, we will have to do this:

@Input() checklists!: Checklist[];

The ! in this context is the non-null assertion operator. It acknowledges the potential null/undefined value and basically says “don’t worry about it, we are sure this will always have a non-null value when we try to use it”. This is an extremely common scenario, and might seem kind of pointless and annoying, but there are cases when the compiler will pick up potentially null or undefined values that we hadn’t considered, and it will force us to handle those properly. In this case we are assuming this component will always be provided with a checklists input that is not null, but it could easily be the case that this component might not immediately be given a non-null value as an input, which could cause a runtime error that would break our application.

This will likely annoy you, especially if you are a beginning and not overly comfortable with how TypeScript works. This is a good thing, it will point out the things you need to learn and soon enough the strict TypeScript compiler will become your overly cautious friend who you are glad to have around (they just need a little re-assuring sometimes).

I actually have a public video that walks though some common scenarios with the strict compiler, you can check it out here.

Restructure the Application

The default blank start application gets us pretty close to where we want to be, but we are going to make a few changes. Specifically, we want modify the default project so that it:

• Uses single file components
• Uses OnPush change detection
• Uses an inline SCAM (Single Component Angular Module)