Why did I migrate my [blog](https://github.com/cesalberca/blog) for the third and last (hopefully) to Web Components? In this article I'll explain why.



## Why?

Initially my blog was powered by [Jekyll](https://jekyllrb.com/), then I migrated it to [Vue](https://vuejs.org/) and last week I was thinking about migrating it to [Nuxt](https://nuxtjs.org/) so that I could improve my SEO and performance. In the last moment I decided to approach it with a more _agnostic_ solution that could also improve my SEO. So I finally decided to migrate it to [LitElement](https://lit-element.polymer-project.org/).

Why this change all of a sudden? Well, I was starting to wonder things that I had taken for granted: Is it so hard to have good SEO without using techniques like SSR or some frameworks like static site generators like [Gatsby](https://www.gatsbyjs.org/)? Is it really necessary to add dependencies with **thousands upon thousands of lines of code**, with **so many moving parts** and **so many abstractions** to build a website nowadays? It _can't be that hard_. Or at least it shouldn't be. That's when [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) come into play, which a part from removing the need of using a complex framework they have [good SEO](https://developers.google.com/search/docs/guides/javascript-seo-basics#web-components).

> It can't be _that complicated_.

When I started my blog in Vue there wasn't a possibility to use Web Components which would work on all modern browsers, but today, it is a possibility. If choosing Web Components means also that I **bet on the platform**, **have less moving parts**, **fewer dependencies**, **less magical transpilation**, then I would have less surface for errors and that would make my code **more robust**, so it would **last longer**.

Here you have the code for my blog: [https://github.com/cesalberca/blog](https://github.com/cesalberca/blog). Without further ado, let's answer the very first question: **how do we serve Web Components?**

## Bundling web components

To serve Web Components we should start looking to include [Webpack](https://webpack.js.org/) o [Parcel](https://parceljs.org/), right? But now that we are rethinking everything, do we really need a bundler? Yes, it seems like a crazy idea, right? Do we really need to create a single file —a bundle— to serve to the client? Why is it necessary today when ESModules are [supported by all modern browsers](https://caniuse.com/#feat=es6-module).

> Do we really need a bundler?

All of these questions led me to choose [Snowpack](https://www.snowpack.dev/), which proposes taking the dependencies and moving them to a `web_modules` and in our code instead of doing:

```typescript
import { customElement } from 'lit-element'
```

We do this:

```typescript
import { customElement } from '/web_modules/lit-element.js'
```

Because the first way of importing is not native —not now [at least](https://github.com/WICG/import-maps)— and browsers don't understand, that's why the piece of the bundler was so **import**ant. Every time the bundler saw some import it would associate it with `node_modules` and so it included the related code in the bundle.

### Snowpack

To use Snowpack you have to take into account the following:

1. The imports must include the extension. At least if we don't want to use Babel (although we can avoid putting the extension with [this configuration](https://www.snowpack.dev/#importing-packages-by-name))
   . With TypeScript, you have to include the extension `.js`. There is an [issue](https://github.com/microsoft/TypeScript/issues/16577) where this is mentioned.
2. When you install dependencies you have to include them in the `package.json` inside the [Snowpack configuration](https://www.snowpack.dev/#whitelisting-dependencies). In my case it was necessary because I wanted to use RxJS, which has the same problems with certain exports.

```json
{
  "snowpack": {
    "webDependencies": [
      "lit-html",
      "lit-element",
      "lit-html/directives/class-map.js",
      "lit-html/directives/style-map.js"
    ],
    "dedupe": ["lit-element", "lit-html"]
  }
}
```

If you find that this command works:

```bash
snowpack --include "src/**/*.ts"
```

Then don't whitelist the dependencies inside the `webDependencies` option.

Although be careful, because the moment you add a web dependency the `--include "src/**/*.ts"` does not do anything, so you should remove it.

3. You need to launch a local server. Opening the `index.html` file won't work because of the script type module. In this case I chose [servor](https://github.com/lukejacksonn/servor) because of its simplicity and its option of auto-reload.

4. Regenerate the `web_modules` when you add a new dependency. You can add a script `prepare` to do so:

```json
{
  "prepare": "snowpack"
}
```

5. If you use [inversify](http://inversify.io/) with [inversify-props](https://github.com/CKGrafico/inversify-props) then you should add the following configuration in the `package.json`:

```json
{
  "snowpack": {
    "namedExports": {
      "inversify-props": ["injectable", "inject"]
    }
  }
}
```

That is probably all you need to know for now of Snowpack, a tool that **saves us the bundle generation time**, which can shave off precious seconds in developments and **avoids complexity**.

## Migration process

In my projects I bet on an architecture which **separates the logic of what my application does from how the user interacts with system**. I often follow an architecture with 4 layers: **application**, **domain**, **infrastructure** and **ui**. This has allowed me to migrate from Vue to LitElement changing mainly the **ui** layer. If you want to know more about this you can watch a talk a gave about [this](https://www.youtube.com/watch?v=NpjecaAgcVQ) (in Spanish).

What other layers did I need to change? The **infrastructure** layer, because when you don't have bundler the imports of Markdown are handled by Webpack with [frontmatter-markdown-loader](https://www.npmjs.com/package/frontmatter-markdown-loader). I had to replace the retrieval of articles with HTTP requests using [Fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API).

Something so simple as importing non JavaScript files was something that was primarily introduced by Webpack and other bundlers, but is something not native, not [at moment](https://github.com/tc39/proposal-module-attributes) at least. Moreover, CSS, image and SVG imports inside JavaScript can be replaced by the use of link, img tags and inlining SVG respectively.

Something that I like about Vue is the reactivity and how you can even create reactive objects outside of the components using the [Vue.observable](https://vuejs.org/v2/api/#Vue-observable) API. I was using this API mainly to handle the little state I have, which is to change the language and theme. With LitElement there is nothing like this, and as I didn't want to couple the state with the view I had to rely on a solution like [RxJS](https://rxjs-dev.firebaseapp.com/) where I stored the state in a BehaviourSubject.

Something that I missed was to avoid prop drilling using the [Provide/Inject](https://vuejs.org/v2/api/#provide-inject) API. With LitElement there is nothing like this or React's [context API](https://reactjs.org/docs/context.html) (which is where the Provide/Inject API comes from). Now that I have my state centralized and being able to do dependency injection with [inversify-props](https://github.com/CKGrafico/inversify-props) I could emulate this functionality.

## Configuration

We don't need a bundler, but we still need to execute certain tasks. For example, when we compile TypeScript, it doesn't copy the HTML, CSS and assets files in the compiled sources. Moreover, something like minifying images which was so simple with a Webpack plugin now we have to do it invoking the image processing library.

At the end everything has its pros and cons. This I would say has been the biggest con, and that is that **many tools are not really adapted to ESModules**.

### Development

The copying of files I do it with [cpx](https://www.npmjs.com/package/cpx) which has a watch mode. I included this in the `package.json`:

```json
{
  "scripts": {
    "prestart": "run-s -l clean",
    "start": "run-p -l server copy:watch compile:watch",
    "clean": "rimraf dist",
    "copy:watch": "run-p copy:assets:watch copy:dependencies:watch",
    "copy:assets:watch": "cpx \"src/**/*.{jpg,jpeg,svg,png,css,html,ico,md}\" dist/ -w",
    "copy:dependencies:watch": "cpx \"web_modules/**/*.js\" dist/web_modules -w",
    "compile:watch": "tsc -w",
    "server": "servor dist index.html --reload --browse",
    "dependencies": "snowpack",
    "prepare": "run-s dependencies"
  }
}
```

You'll see that I make use of the weird commands: `run-s` and `run-p`. Well, I use that in order to execute several processes at the same time, like the compiler watch, the copying watch and the local server. You can't wait for one process to finish to start another one because it will never finish executing, not until we stop it manually.

`run-s` and `run-p` come from the package [npm-run-all](https://www.npmjs.com/package/npm-run-all). The `s` means "sequentially" and the `p` means "parallel".

With an `index.html` file where we import a script with type module we will be able to see something:

```html
<!DOCTYPE html>
<html lang="es">
  <head>
    <link rel="stylesheet" rel="preload" href="ui/styles/base.css" />
    <script type="module" src="./index.js"></script>
  </head>
  <body>
    <cesalberca-blog></cesalberca-blog>
  </body>
</html>
```

### Production

To make the production build we will need to have a script similar to the `start` script except we won't need the watch mode. I also minify the images here. I don't do any other type of [minification](<https://en.wikipedia.org/wiki/Minification_(programming)>), [uglifying](https://www.quora.com/What-does-uglify-mean) or [tree shaking](https://en.wikipedia.org/wiki/Tree_shaking). I'm aware of the costs of not doing this and for the moment I think they are trivial to the user.

Something that we get for free without a bundle is that the browser will cache the files for you.

The `package.json` now looks like this:

```json
{
  "scripts": {
    "prebuild": "run-s -l clean",
    "build": "run-s -l dependencies copy compile",
    "postbuild": "run-s optimize",
    "clean": "rimraf dist",
    "copy": "run-s copy:assets copy:dependencies",
    "copy:assets": "cpx \"src/**/*.{jpg,jpeg,svg,png,css,html,ico,md}\" dist/",
    "copy:dependencies": "cpx \"web_modules/**/*.js\" dist/web_modules",
    "compile": "tsc",
    "optimize": "ts-node scripts/optimize.ts",
    "dependencies": "snowpack",
    "prepare": "run-s dependencies"
  }
}
```

### TypeScript

In order for TypeScript's type resolution to work I had to add the following configuration to `tsconfig.json`:

```json
{
  "compilerOptions": {
    "rootDir": "src",
    "baseUrl": ".",
    "paths": {
      "/web_modules/*.js": ["node_modules/@types/*", "node_modules/*", "web_modules/*.js"]
    }
  }
}
```

So now when we do an import from `/web_modules` TypeScript knows to resolve the imports from `node_modules`.

Moreover, I had to add `inlineSourceMap` and `inlineSources` to true in order to be able to debug with breakpoints.

My whole `tsconfig.json` configuration is this:

```json
{
  "compilerOptions": {
    "target": "es2018",
    "module": "esnext",
    "outDir": "dist",
    "moduleResolution": "node",
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "inlineSourceMap": true,
    "inlineSources": true,
    "resolveJsonModule": true,
    "types": ["jest", "reflect-metadata", "node"],
    "lib": ["esnext", "dom", "dom.iterable"],
    "rootDir": "src",
    "baseUrl": ".",
    "paths": {
      "/web_modules/*.js": ["node_modules/@types/*", "node_modules/*", "web_modules/*.js"]
    },
    "allowSyntheticDefaultImports": true
  },
  "include": ["src/*"],
  "exclude": ["node_modules"]
}
```

### Testing

For testing, I use [Jest](https://jestjs.io/). Here I had to adapt the configuration, so it worked correctly. In this case I had to add the following dependencies:

```bash
npm i @babel/core @babel/plugin-proposal-decorators @babel/preset-env @babel/preset-typescript @types/jest babel-jest jest jest-ts-webcompat-resolver -DE
```

As you can see we added Babel, but... Why? Well, Jest **executes directly TypeScript**. However, Jest, does not know how to read a TypeScript file. That's why we need to erase all type information so Jest can parse and execute that file. This is explained more in detail [here](https://iamturns.com/typescript-babel/).

In this case we only need to use Babel for the tests, that's why I included this configuration in the `babel.config.js`:

```javascript
module.exports = {
  env: {
    test: {
      presets: [['@babel/preset-env', { targets: { node: 'current' } }], '@babel/preset-typescript'],
      plugins: [
        [
          '@babel/plugin-proposal-decorators',
          {
            legacy: true,
          },
        ],
      ],
    },
  },
}
```

Lastly my `jest.config.js`:

```javascript
module.exports = {
  coverageDirectory: 'coverage',
  coverageReporters: ['text-summary', 'lcov'],
  resolver: 'jest-ts-webcompat-resolver',
  moduleNameMapper: {
    '/web_modules/(.*)': '<rootDir>/web_modules/$1',
  },
  setupFiles: ['<rootDir>/tests/set-up.ts'],
}
```

The [jest-ts-webcompat-resolver](https://www.npmjs.com/package/jest-ts-webcompat-resolver) is a package that helps resolve imports from TypeScript with the extension.

With that we can now run our tests.

## Conclusions

The code of my blog you can read it [here on Github](https://github.com/cesalberca/blog). I'm very satisfied with the result. I employed a lot of time investigating how to approach common problems in the most native way. At the end I managed to achieve my objectives: **have a better SEO**, **simplify** and **bet on the platform**.

I think for now tooling must try and adapt to the modern way of doing things and leave behind non-native APIs. It's something that [Deno](https://deno.land/) is doing. It's something that LitElement is doing. **And it's something that we should be doing**.

Why I migrated my blog to Web Components?

In this tutorial we will see how to migrate a codebase from JavaScript to [TypeScript](https://www.typescriptlang.org/). We will migrate the code of my talk Advanced JavaScript Pattern (oh the irony, right?). [Here you have the repository](https://github.com/cesalberca/advanced-javascript-patterns). You can also watch [my talk here in Spanish](https://www.youtube.com/watch?v=3nPPRvRcoo0&feature=youtu.be). Let's start!



## Configuration

First of all is to include a `tsconfig.json` file in the root of your project. This file we will set the options for TypeScript:

```json
{
  "compilerOptions": {
    "moduleResolution": "node",
    "outDir": "./dist",
    "allowJs": true,
    "target": "esnext"
  },
  "include": ["./src/**/*"],
  "exclude": ["node_modules"]
}
```

`moduleResolution` specifies how [TypeScript is going to resolve the dependencies](https://www.typescriptlang.org/docs/handbook/module-resolution.html).

`outDir` will be the directory in which the TypeScript code will be compiled to. This will be the code that we will deploy or execute.

The `allowJs` option allows us to do an incremental migration, **which is great**!

`target` allows us to set the JavaScript version in which we want to compile to. We could also even set it to version `es3` making our code be executable in older browsers.

Lastly, with `include`, we define which routes TypeScript's compiler should be checking. By convention, we should have our code in the `src` directory.

## Installation

Now we install TypeScript as a `dev-dependency`: `npm i typescript -DE`. We add to the scripts of the `package.json` the script of compilation:

```json
{
  "scripts": {
    "compile": "tsc --pretty"
  }
}
```

Because we don't have any `.ts` file that we can compile we'll see that the compilation is successful:

![image-20191112213355655](/assets/images/articles/migrating-to-typescript/image-20191112213355655.png)

## Migration

Let's try change the extension from `.js` to `.ts` and compile again:

![image-20191112213602568](/assets/images/articles/migrating-to-typescript/image-20191112213602568.png)

What?! It compiles correctly! Well yes, **any JavaScript file is valid TypeScript code**.

TypeScript by default infers anything that it doesn't understand as [any](https://www.typescriptlang.org/docs/handbook/basic-types.html#any). `any` is not cool, _not at all_. With the option `noImplicitAny` set to `true` in our `tsconfig.json` we will get an error in places TypeScript infers something to `any`.

```json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}
```

Now when we compile we'll start to see some errors. To fully get TypeScript's advantages like: safety, refactorings and improved DX we need to help it by stating the types we use, and that's what we are going to do:

```javascript
export function multiply(a = 1, b = 1) {
  return a * b
}

export function priceAfterTaxes(price, tax = multiply(21, 0.01)) {
  return price + price * tax
}
```

Will become:

```typescript
export function multiply(a = 1, b = 1) {
  return a * b
}

export function priceAfterTaxes(price: number, tax = multiply(21, 0.01)) {
  return price + price * tax
}
```

Here we see that TypeScript doesn't need us to specify that `a` or `b` in the function `multiply` are `numbers` given that it's smart enough to infer it. Moreover, if it receives two parameters that are numbers, and we multiply them, what would the return type be? Well, obviously `number`.

### Never

Let's check the `propValidator` file:

```javascript
export function isRequired() {
  throw new TypeError('Argument is required')
}

export function capitalize(string = isRequired()) {
  return string.toUpperCase().slice(0, 1) + string.slice(1)
}
```

It becomes:

```typescript
export function isRequired(): never {
  throw new TypeError('Argument is required')
}

export function capitalize(string: string = isRequired()) {
  return string.toUpperCase().slice(0, 1) + string.slice(1)
}
```

`never` is a very interesting type which specifies something that's never going to change. It's not very common to use it, but in this case this function never returns anything. Here we see that TypeScript adapts to the great flexibility that JavaScript offers. It's in very few cases where we can't model a JavaScript program in TypeScript and there is always the `any` escape hatch.

If you want, you can checkout the basic types in [the official documentation](http://www.typescriptlang.org/docs/handbook/basic-types.html)

### Classes

With classes, we see certain advantages in respect to their counterparts in JavaScript:

```javascript
export class Subject {
  constructor() {
    this.observers = []
    this._counter = 0
  }

  set counter(value) {
    // https://github.com/tc39/proposal-private-fields
    this._counter = value
    this.notifyObservers()
  }

  get counter() {
    return this._counter
  }

  incrementCounter() {
    this.counter++
    this.notifyObservers()
  }

  addObserver(observer) {
    this.observers.push(observer)
  }

  notifyObservers() {
    this.observers.forEach(observer => observer.notify(this))
  }
}
```

In TypeScript is:

```typescript
import { Observer } from './Observer'

export class Subject {
  private _counter = 0
  private readonly observers: Observer[]

  constructor() {
    this.observers = []
  }

  set counter(value) {
    // https://github.com/tc39/proposal-private-fields
    this._counter = value
    this.notifyObservers()
  }

  get counter() {
    return this._counter
  }

  incrementCounter() {
    this.counter++
    this.notifyObservers()
  }

  addObserver(observer: Observer) {
    this.observers.push(observer)
  }

  notifyObservers() {
    this.observers.forEach(observer => observer.notify(this))
  }
}
```

Here we don't need to use anymore the convention `_` to specify that a property or method is private. With TypeScript, we have available to us [privacy](http://www.typescriptlang.org/docs/handbook/classes.html#public-private-and-protected-modifiers) with the `private` keyword –we also have `protected` and `public`–. By default, if we don't specify anything, it's `public`.

We also don't need to declare the types and do the assignations in the constructor like we do in the `Observer` file:

```javascript
export class Observer {
  constructor(subject) {
    this.subject = subject
    this.subject.addObserver(this)
    this.value = 0
  }

  display() {
    return `Observer counter: ${this.value}`
  }

  notify(subject) {
    this.value = subject.counter
  }
}
```

We can do as follows:

```typescript
import { Subject } from './Subject'

export class Observer {
  private value = 0

  constructor(private readonly subject: Subject) {
    this.subject.addObserver(this)
  }

  display() {
    return `Observer counter: ${this.value}`
  }

  notify(subject: Subject) {
    this.value = subject.counter
  }
}
```

Moreover, if in the constructor we specify `private` or `public`:

```typescript
class Foo {
  foo: number

  constructor(foo: number) {
    this.foo = foo
  }
}
```

It's the same as this:

```typescript
class Foo {
  constructor(public foo: number) {}
}
```

### Generics

Let's see a more complex example:

```typescript
// Well later see how we can improve the any return type
export function createSafe(target: object): any {
  const handler = {
    get(target: object, name: string | number | symbol, receiver: any) {
      if (hasKey(target, name)) {
        const targetElement = Reflect.get(target, name, receiver)

        if (isObject(targetElement)) {
          return createSafe(targetElement)
        }

        return targetElement
      }

      return notDefined
    },
  }
  return new Proxy(target, handler)
}

export const notDefined: object = new Proxy(
  {},
  {
    get() {
      return notDefined
    },
  },
)

export const either = (value: object, fallback: any) => (value === notDefined ? fallback : value)

const isObject = (obj: object) => typeof obj === 'object'
const hasKey = (obj: object, key: string | number | symbol) => key in obj
```

Let's improve the types, because we are making use of `any` and we shouldn't. Given the nature of the [proxies](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) that we are creating, the return type is the same as the type of element we are passing through the parameter of the function. Right now as we are marking it as `any` we could make mistakes and TypeScript wouldn't be able to tell us:

```typescript
const object = createSafe({ foo: 'bar' })
object.propertyThatDoesNotExist // OK
```

So we'll have a runtime error because we couldn't catch it in compilation. We can't even get the IDE to tell use what properties this object has. So let's be more exact with the types:

```typescript
export function createSafe<Target>(target: Target): Target {
  const handler = {
    get(target: Target, name: string | number | symbol, receiver: any) {
      if (hasKey(target, name)) {
        const targetElement = Reflect.get(target, name, receiver)

        if (isObject(targetElement)) {
          return createSafe(targetElement)
        }

        return targetElement
      }

      return notDefined
    },
  }
  return new Proxy(target, handler)
}
```

Here we are making use of a [generic](https://www.typescriptlang.org/docs/handbook/generics.html). Generics allow us to define a type which can take different values overtime, which is what we need for this function. Given that we have only one parameter TypeScript knows that the parameter `target` will obtain the value of the `Target` type:

```typescript
const foo = createSafe('hello') // foo is inferred as a string
const bar = createSafe(1) // bar is inferred as a number
```

Yet if we compile we'll see that we get the following error:

![image-20191113201553918](/assets/images/articles/migrating-to-typescript/image-20191113201553918.png)

What happened? Well, given that any type can be set to `Target` that raises a problem, as we only want `Target` to take any type that is of an object kind. So what we want here is [to constrain the type](https://www.typescriptlang.org/docs/handbook/generics.html#generic-constraints) that we can assign to `Target` to the `object` type:

```typescript
export function createSafe<Target extends object>(target: Target): Target {
	...
}
```

With `Target extends object` we are stating that `Target` can only be of type `object`.

Uff, César, this seems very complex, right? Well, yes, I wanted to show a complex example just in case you have a similar problem. The rest of the code was pretty straightforward, right?

## We become stricter

What if I told you that you can make you program fireproof? Well, you can, here the [strict more](https://www.typescriptlang.org/docs/handbook/compiler-options.html) comes into play:

```json
{
  "compilerOptions": {
    "strict": true
  }
}
```

With this option TypeScript will offer more checks like nulls, this, bind, call, apply and property initialization. I also like setting the following options:

```json
{
  "compilerOptions": {
    "strict": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedParameters": true,
    "noUnusedLocals": true,
    "forceConsistentCasingInFileNames": true
  }
}
```

Now TypeScript will tell me when did I miss adding a branch in a switch statement, when did I put a parameter in a function that I don't use, when I don't use a symbol, when all the branches of a function return a value or when I'm not being consistent of the capitalization of imports in different files.

## Tests

This project has tests done with [Jest](https://jestjs.io/). In any refactor is a good idea to have a safety net like a test suite. If we make mistakes the tests will tell us. We also have TypeScript to check errors, but if TypeScript has errors, we won't be able to compile and deploy to production, right? Well, no, TypeScript always compiles to JavaScript, we could just _simply_ ignore the errors. Although, are you sure you want to deploy a program with possible errors?

Let's run the tests:

```bash
npm test
```

![image-20191113202705616](/assets/images/articles/migrating-to-typescript/image-20191113202705616.png)

Oups, what is happening? Well, [Jest](https://jestjs.io/), the test runner that we are using, doesn't know how to compile TypeScript, which requires some configuration. We add [Babel](https://babeljs.io/) so it can erase the types and then run the tests:

```bash
npm i @babel/preset-typescript -DE
```

We need to create a `babel.config.js` file in the root of our project:

```typescript
module.exports = {
  presets: ['@babel/preset-typescript'],
}
```

We add some configuration to `jest.config.js`:

```typescript
module.exports = {
  ...
  rootDir: 'src',
  moduleFileExtensions: ['ts', 'js']
}
```

And we run the tests!

![image-20191115194956149](/assets/images/articles/migrating-to-typescript/image-20191115194956149.png)

## Conclusion

If you want to see all the code that I migrated checkout this [pull request](https://github.com/cesalberca/advanced-javascript-patterns/pull/8/files). If you still have some doubts you can check this other [Spanish article I wrote](https://www.adictosaltrabajo.com/2018/08/01/typescript-vs-javascript/).

And now _what_? Well, you'll see the great advantages that TypeScript provides us like fewer bugs, be able to make a simple refactor as renaming a symbol, or a program that has a living documentation. This and many other advantages just by using TypeScript.

Migrating to TypeScript

You want to change [Karma](https://karma-runner.github.io/latest/index.html) in an Angular application to a better test runner like [Jest](https://jestjs.io/)? Then this tutorial is the one you were looking for!



[Jest](https://jestjs.io/) is a test runner created by Facebook based in Node. Is this last bit which makes it so fast compared to Karma, given that you don't need a browser to execute the tests. Even if you launch Karma headless, Jest still beats Karma running the same test suite for up to **3 times**.

So let's begin!

The first step is to execute this command:

```bash
npm uninstall -DE karma karma-chrome-launcher karma-coverage-istanbul-reporter karma-jasmine karma-jasmine-html-reporter @types/jasmine @types/jasminewd2 jasmine-core jasmine-spec-reporter
```

With this, we will remove the billion dependencies that you need to execute Karma.

Next, we will remove these files: `karma.conf.js` and `src/test.ts` using this command:

```bash
rm ./karma.conf.js ./src/test.ts
```

Now we will delete from `types` the property `jasmine` and we'll remove from the `files` option the property `src/tests.ts` in the `tsconfig.spec.json`. Our file should end up like this:

```json
{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["node"]
  },
  "files": ["src/polyfills.ts"],
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}
```

We add to the `tsconfig.json` the following under `compilerOptions`:

```json
{
    ...
    "compilerOptions": {
        "types": ["jest"]
    }
    ...
}
```

We install `jest` and `builder-jest`:

```bash
npm i -DE jest @types/jest @angular-builders/jest
```

Now, in `angular.json` we replace this configuration:

```json
{
  "test": {
    "builder": "@angular-devkit/build-angular:karma",
    "options": {
      "main": "src/test.ts",
      "polyfills": "src/polyfills.ts",
      "tsConfig": "tsconfig.spec.json",
      "karmaConfig": "karma.conf.js",
      "assets": ["src/favicon.ico", "src/assets"],
      "styles": ["src/styles.css"],
      "scripts": []
    }
  }
}
```

with this one:

```json
{
  "test": {
    "builder": "@angular-builders/jest:run"
  }
}
```

Lastly, we add inside `tsconfig.spec.json` in the option `compilerOptions`: `"esModuleInterop": true`.

We can execute `ng test` and it will run the tests using Jest!

In conclusion, not only did we manage to run our tests faster, we also make the breakpoints launch with a higher success rate, we needed fewer dependencies, fewer configuration, and we'll have features that Jest provides us like [test.each](https://jestjs.io/docs/en/api#1-testeachtable-name-fn-timeout), [snapshot testing](https://jestjs.io/docs/en/snapshot-testing) and [utilidades para mockear](https://jestjs.io/docs/en/mock-functions).

And if you have already started a project, and you want to migrate to Jest I recommend that you checkout out [this codemod](https://github.com/skovhus/jest-codemods) which will migrate most of the code to Jest.

Jest Angular

Theming a web with custom properties is as easy as it gets as shown in this article.



Theming is such an important aspect of web development, and even though your app or website might not require different themes we should develop our visual styles such as color, spacing, fonts and animations as if they were to change every day. Why? Because it is what changes most often. If done well, a rebranding, introducing a "dark mode" or adjusting colors will be super easy.

> "we should develop our visual styles such as color, spacing, fonts and animations as if they were to change every day."

## Custom properties

CSS's Custom properties are truly a gift. They open up so many possibilities because of their dynamic behaviour. We can create a new custom property in a given element as follows:

```css
.class {
  --a-custom-property: 42px;
}
```

Now every child of that element has access to this custom property:

```css
.class-child {
  margin-bottom: var(--a-custom-property);
}
```

We can even set default values in case the property is not declared:

```css
.class-child {
  margin-bottom: var(--a-custom-property, 12px);
}
```

And what is even more amazing is that we can change dynamically the values of custom properties via CSS or JavaScript:

```css
@media (max-width: 800px) {
  .class-child {
    --a-custom-property: 56px;
  }
}
```

_Note: One would think that we can declare variables for the values of media queries but we can't, we'll have to wait until [env](https://developer.mozilla.org/en-US/docs/Web/CSS/env) lands in Edge and Internet Explorer to have full support (as of June 2019)._

## Theming

So, using custom properties how can we theme an app? Well, we first start by creating a `colors.css` file:

```css
:root {
  --white-color: hsla(0, 0%, 100%, 0.88);
  --white-light-color: hsl(0, 0%, 98%);
  --black-color: hsl(0, 1%, 15%);
  --dark-blue: hsl(222, 14%, 18%);
  --gray-color: hsl(150, 2%, 79%);
  --blue-color: hsl(229, 87%, 44%);
  --blue-light-color: hsl(206, 68%, 55%);
  --blue-dark-color: hsl(219, 16%, 16%);
  --teal-color: hsl(184, 97%, 37%);
  --orange-color: hsl(32, 100%, 50%);
}
```

_Note: The `:root` selector targets the root element of a document._

Now, if the color changes slightly to another one, we should change this file. But, should we still reference this in our components or CSSs? The answer is no, we should have another indirection. Imagine the following case. We declare in every component to use the custom property `--orange-color`. However, a new redesign requires a change of the main color of the app (which is the `--orange-color`) to a blue color. Now, in order to make it work we could do something like this:

```css
:root {
  --orange-color: blue;
}
```

But this is so bad at so many levels. For one, we have names that don't represent what they stand for and can misguide developers. What if we create a new custom property `--real-blue: darkblue;`? This for sure will ensue madness.

How can we tackle this problem? The answer lies in a previous paragraph: "requires a change of the main color of the app". What we need to identify is the main color of the app, also known as **primary color**. After that we should identify a **secondary color** or other colors and what do they represent. We can handle all this in a new file called `palette.css`:

```css
:root {
  --primary-color: var(--orange-color);
  --secondary-color: var(--teal-color);
}
```

Another thing I like to do is declare the foreground and background color, this allows me to create in a future a dark theme or a light theme:

```css
:root {
  --foreground-color: var(--black-color);
  --background-color: var(--white-color);
}
```

In order to change to a dark color mode we can just swap the values:

```css
:root {
  --foreground-color: var(--white-color);
  --background-color: var(--black-color);
}
```

## Conclusion

Theming as shown in this tutorial can save you a lot of headaches if done well. However we must be precise on what custom properties we assign to our components and try to identify as much as we can business concepts. For example, some error state can be represented today as red, so we should have an `--error-color: var(--red-color);` property and if it changes tomorrow we can do it easily `--error-color: var(--orange-color);`.

Theming

Use cases and commands. How to.



The [command pattern](https://sourcemaking.com/design_patterns/command) helps us encapsulate requests in order to perform certain operations, like logging, queuing and filtering.

We start with the interface:

```typescript
export interface Command<T> {
  execute(): Promise<T>
}
```

And then we can look at a specific command, for example the one used to retrieve this article:

```typescript
import { Command } from '../../infraestructure/Command'
import { Article, ArticlesRepository } from '../../domain/articles'
import { Id } from '../../domain'
import { Locale, Translator } from '../../domain/language'
import { ArticlesFileRepository } from '../../infraestructure/articles/ArticlesFileRepository'
import { FileLoader } from '../../infraestructure/FileLoader'
import { TranslationService } from '../../domain/TranslationService'

export class GetArticle implements Command<Article> {
  constructor(
    private readonly articlesRepository: ArticlesRepository,
    private readonly id: Id,
    private readonly locale: Locale,
  ) {}

  async execute(): Promise<Article> {
    return this.articlesRepository.findOneByLocale(this.id, this.locale)
  }

  static create(context: { id: Id; locale: Locale }) {
    return new GetArticle(
      new ArticlesFileRepository(FileLoader.create(), TranslationService.create(Translator.create())),
      context.id,
      context.locale,
    )
  }
}
```

This command is responsible for obtaining a certain article using a [repository](http://shawnmc.cool/the-repository-pattern), where and how do we get this data we neither know nor care, that's responsibility of another class.

This command represents a [Use Case](https://en.wikipedia.org/wiki/Use_case) of my application. Right now it only needs to get the article from the repository but in the feature it could handle if a user has read the article, or if the user is a PRO user and then can read all articles instead of a subset of articles or anything we'd like.

Who builds the command? Whoever uses it:

```typescript
const article = await GetArticle.create({
  id: 'use-cases-and-commands',
  locale: Locale.EN,
}).execute()
```

I'm using [inversion of control](https://en.wikipedia.org/wiki/Inversion_of_control) to provide the dependencies needed for the GetArticle use case to work. In this case I'm going from an abstraction (ArticlesRepository) to a concreation (ArticlesFileRepository). If tomorrow I decide to serve the articles via API I would only need to change the factory.

What is also interesting about commands is that they are easily augmented. For example we can log when a command is executed without touching any commands using the [Decorator Pattern](https://sourcemaking.com/design_patterns/decorator):

```typescript
import { Command } from './Command'
import { Logger } from './Logger'

export class LoggerCommandDecorator<T> implements Command<T> {
  constructor(private readonly decoratedCommand: Command<T>, private readonly logger: Logger) {}

  execute(): Promise<T> {
    this.logger.log(
      (this.decoratedCommand as Object).constructor.name + ' - ' + Object.getOwnPropertyNames(this.decoratedCommand),
    )
    return this.decoratedCommand.execute()
  }
}
```

Then, using a `UserCaseDecorator` I specify which decorators I want for **all my use cases**:

```typescript
import { Command } from '../../infraestructure/Command'
import { LoggerCommandDecorator } from '../../infraestructure/LoggerCommandDecorator'
import { Logger } from '../../infraestructure/Logger'

export class UseCaseDecorator {
  private static readonly logger = Logger.create({
    // eslint-disable-next-line
    stdout: { error: console.error, info: console.log, warn: console.warn },
  })

  static decorate<T>(command: Command<T>) {
    return new LoggerCommandDecorator<T>(command, UseCaseDecorator.logger)
  }
}
```

And then in each use case we use the `UseCaseDecorator` like so:

```typescript
import { Command } from '../../infraestructure/Command'
import { Article, ArticlesRepository } from '../../domain/articles'
import { Id } from '../../domain'
import { Locale, Translator } from '../../domain/language'
import { UseCaseDecorator } from './UseCaseDecorator'
import { ArticlesFileRepository } from '../../infraestructure/articles/ArticlesFileRepository'
import { FileLoader } from '../../infraestructure/FileLoader'
import { TranslationService } from '../../domain/TranslationService'

export class GetArticle implements Command<Article> {
  constructor(
    private readonly articlesRepository: ArticlesRepository,
    private readonly id: Id,
    private readonly locale: Locale,
  ) {}

  async execute(): Promise<Article> {
    return this.articlesRepository.findOneByLocale(this.id, this.locale)
  }

  static create(context: { id: Id; locale: Locale }) {
    return UseCaseDecorator.decorate(
      new GetArticle(
        new ArticlesFileRepository(FileLoader.create(), TranslationService.create(Translator.create())),
        context.id,
        context.locale,
      ),
    )
  }
}
```

And we could create as many decorators as we want and use composition to give more behaviour to our commands.

Use Cases and Command Pattern

I’m a self-learning, creative, enthusiast and passionate person. I have a mixed profile, divided between my love for programming, software architecture and design. I truly care about sharing knowledge with my peers, that being as a speaker in different technological events, as a teacher or throughout my social networks.

I believe that Software should be robust yet flexible, and the way to achieve it is to –regardless of the framework– create the right abstractions and apply architectural patterns. Testing is very important to me, the Software we build should be reliable in order to provide the maximum value.