DEV Community: Lucas Paganini

Mocking Concepts - What is Mocking

Lucas Paganini — Tue, 25 Oct 2022 20:13:30 +0000

What is Mocking

Welcome to the second article in our software testing series! The last article explored static, unit, integration, and end-to-end tests.

In this article, we'll explore:

What is mocking?
What are the core concepts behind it?
When to mock and when not to mock?
What are the best practices for mocking?

We won't go deep into fake data, stubs, drivers, spies, or any of that. We'll just focus on the mental model around mocking. Everything else can come later.

So, what is mocking?

Mocking is the process of simulating the external dependencies of the code that's being tested. Thus, isolating your code from the multitude of things it depends on.

This "simulation" can come in two forms:

Fake data
Fake interactions

Fake Interactions

For example, let's say you want to test a function that requires a connection to a database. The function may depend on a database, but the database is not the focus here. The focus is the function itself. We're not testing the database or the database connection. We're just testing a function that depends on those things.

export interface User {
  id: string;
  name: string;
}

export interface DatabaseConnection<T extends { id: string }> {
  findOneByID: (id: T['id']) => Promise<T | null>;
}

/**
 * Grabs the user by its ID and returns its name.
 * Returns "Unknown" if we can't find a user with that ID.
 */
export const getUserName = async (
  db: DatabaseConnection<User>,
  userID: string
): Promise<string> => {
  const maybeUser: User | null = await db.findOneByID(userID);
  return maybeUser?.name ?? 'Unknown';
};

Sure, by providing an actual database connection, we ensure that our test is more "real". But that comes at the expense of complexity and maintainability. Instead, we could just provide a fake database to our function.

That fake database is considered a mocked interaction, because it mocks (fakes) something that our function interacts with.

export const createMockedDatabaseConnection = <T extends { id: string }>(
  data: Array<T>
): DatabaseConnection<T> => ({
  findOneByID: async (id) => data.find((el) => el.id === id) ?? null,
});

Fake Data

We also have mocked data, which is fake data used in tests.

For example, the fake database we provided was just so that we could start testing our function. Now that we have all the interactions that our function depends on, we need to actually test it. And how do we do that? By passing inputs and expecting certain outputs.

To pass inputs, we need data. And this doesn't need to be actual data from your real database. We can use mocked (fake) data.

describe('getUserName()', () => {
  it('Returns the correct user name', async () => {
    // Fake data
    const fakeUser: User = { id: '1', name: 'Joe' };

    // Fake interactions
    const fakeDatabase: DatabaseConnection<User> =
      createMockedDatabaseConnection([fakeUser]);

    // Assertions
    const actualUserName = await getUserName(fakeDatabase, fakeUser.id);
    expect(actualUserName).toBe(fakeUser.name);
  });
});

In this example, we create a fake user called Joe with ID 1.

When to Mock

A common concern is when to mock. After all, we could have used an actual database in our tests above. So how can we decide when we should mock?

First, let's take a look at the pros and cons of mocking:

Pros

Less setup because it doesn't come with all the dependencies of an actual database;
No cleanup because we're not saving anything to an actual database, so if there’s no persistent state, there’s nothing to clean;
Faster because (again) it doesn't have to create all the dependencies of an actual database;
Isolated because our tests will still pass even if the actual database breaks.

Regarding that last point, it might sound bad that our test passes even though it wouldn't pass with an actual database. I was skeptical about this too, but here's the reasoning: If the database is broken, only the database tests should fail, not the tests that depend on the database.

The advantage of this isolation is debuggability.

Without mocking

❌ Database tests
❌ Payment tests
❌ User creation tests
❌ Blog tests

Mocking

❌ Database tests
✅ Payment tests
✅ User creation tests
✅ Blog tests

Imagine that you have a thousand tests that depend on the database. If they're using the real database instead of a mock, all these tests will fail, leaving you with the task of figuring out why everything is crashing. But if the tests are isolated, only the database tests will fail, so you know exactly where to look.

Cons

Less confidence because you're not using real interactions (or data).

Confidence is the keyword here. You have to consider that every time you mock something, You are creating a fake environment, so that begs the question: will it work in the real environment? That really depends on how well the test is written, but still, it’s not the real environment, so a test that uses mocking can’t provide the same confidence as a test that doesn’t use mocking.

There's no silver bullet. No magic answer. You have to ponder each case individually. How much confidence are you willing to give up?

To me, the answer is none. But I also don't want to give up on all the benefits of mocking. So instead of choosing between:

Fast, mocked tests;
Or slow, real, end-to-end tests.

I choose both.

As mentioned in the previous article, we run all types of tests here.

For immediate feedback, we run unit and integration tests on every file change. These tests must run very fast, so for them, we use mocked data and mocked interactions.

Then, when we open a pull request, our continuous integration pipeline spins up a staging environment where we run our end-to-end tests with fake data but no fake interactions.

That combination makes me confident that my code works when all the test passes.

Best Practices of Mock Testing

Now, supposing that you've already decided to use mocks, here are some best practices:

1. Only mock types that you own

External types can change at any time, so don't mock them. Notice that we're talking about types, not actual values. You can totally mock a third-party library. Just don't mock their type signature.

// ✅ Do that

import FooType from 'FooLib';

describe('Foo', () => {
  it('Expects foo return a foo type', async () => {
    const foo: FooType = { ... };
    const result = returnFoo();
    expect(result).to.deep.equal(foo);
  });
});

function returnFoo(): FooType {
  return { ... };
}

// ❌ Don't do that

type FooType = { ... };

describe('Foo', () => {
  it('Expects foo return a foo type', async () => {
    const foo: FooType = { ... };
    const result = returnFoo();
    expect(result).to.deep.equal(foo);
  });
});

function returnFoo(): FooType {
  return { ... };
}

2. Don't mock return values of what's being tested

Think about this for a second. Mocking return values of our testing subject doesn't even make sense. Imagine writing tests for a sum() function and mocking it to always return 3. That doesn’t let us know if our function is actually working.

// ✅ Do that

describe('sum()', () => {
  it('Returns a sum of 1 and 2', async () => {
    const sumResult = sum(1, 2);
    expect(sumResult).to.equal(3);
  });
});

// ❌ Don't do that

describe('sum()', () => {
  it('Returns a sum of 1 and 2', async () => {
    const mockedSum = jasmine.createSpy('sum', sum).and.returnValue(3);
    const sumResult = mockedSum(1, 2);
    expect(sumResult).to.equal(3);
  });
});

3. Don't mock everything

This is an anti-pattern. If everything is mocked, we may test something quite different from the production environment. It's like we've talked before. The more you mock, the less confidence you have in that test. If you mock everything, then it provides no confidence that it will work in the production environment.

4. Use integration tests

If you care about how your code interacts with other modules, you should do integration testing rather than mocking.

5. Test failing cases

While creating your mocks, don't forget to simulate errors and test error handling. You can even add expectations that some methods or API calls should not be made in case of an error.

describe('getUserName()', () => {
  it('Returns an Error when the req fails', async () => {
    // Fake data
    const fakeUser: User = { id: '1', name: 'Joe' };
    const wrongId = '2';

    // Fake interactions
    const fakeDatabase: DatabaseConnection<User> =
      createMockedDatabaseConnection([fakeUser]);

    // Assertions
    const actualUserNamePromise = getUserName(fakeDatabase, wrongId);
    await expectAsync(actualUserNamePromise).toBeRejectedWithError(Error);
  });
});

Don't Stop Here

That's all for concepts. In the following articles, we'll talk more about fake data and fake interactions.

If you want to dive deeper into software testing, consider subscribing to our newsletter. It's spam-free. We keep the emails few and valuable. If you prefer to watch our content, we also have a YouTube channel that you can subscribe to.

And if your company is looking for remote web developers, consider contacting my team and me. You can do so through email, Twitter, or Instagram.

Have a great day!

– Lucas

References

What's new in Angular 14?

Lucas Paganini — Fri, 26 Aug 2022 23:02:56 +0000

Discover what changed!

Introduction

Angular 14 was recently released with a bunch of exciting features. And today, I'll present them to you. They are:

Standalone components
Route Providers
ENVIRONMENT_INITIALIZER
Typed Forms
The inject() Function
Setting the Page title from the route
Autocomplete in the Angular CLI
Optional injectors in Embedded Views

So let's get started!

Standalone components

For most people, the most significant change in this version is the possibility of creating components without @NgModules! Yeah, you got that right.

Before Angular 14

If you are a bit lost, let me show you a folder structure from a classic Angular component:

home 
| --home.component.html
|--home.component.css
|--home.component.ts
|--home.module.ts;

There, we have an .html file for the template, a .css file for the styles, a .ts file for the component, and another .ts file for the @NgModule. This last file imports the dependencies of our component, declares the component, and can also define some providers.

A new possibility with Angular 14

In Angular 14, we can do all that directly in the component, without needing an @NgModule.

home 
|--home.component.html 
|--home.component.css 
|--home.component.ts;

To do that, we just need to set the standalone property in our component to true.

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.scss'],
  standalone: true,
})

Be aware!

Be aware:

Standalone components are not the new way of declaring components! They are another way of declaring components. The classic way of defining @NgModules will not be deprecated.

Well, I can't really promise that it won't be deprecated. But yeah, so far, there are no intentions of deprecating @NgModules.

As a matter of fact. I will still use @NgModules instead of standalone components because I like the isolation that @NgModules provides.

Don’t migrate your entire application to standalone components yet! Standalone components are very recent, and it will take us a while to create conventions and define best practices. I recommend waiting a bit longer before jumping ship.

Route Providers

But hey, if we drop the @NgModule and use standalone components, how can we set provider by route, like we used to do with @NgModules?

To address that, Angular added route providers. So, basically, route definitions now have a property called providers. Allowing us to provide values only to the modules and components rendered by that route.

const NAME = new InjectionToken<string>('token');

export const routes: Routes = [
  {
    path: '',
    component: HomeComponent,
    providers: [
      {
        provide: NAME,
        useValue: 'foo'
      }
    ]
  }
];

ENVIRONMENT_INITIALIZER

Another thing we used to do with NgModules was run a setup script when a lazy loaded module was initialized. In other words, the constructor of a lazy loaded module would only run when the module was initialized, and some developers take advantage of that to run some kind of setup.

export class HomeModule {
  constructor() {
    console.log('You can run something here');
  }
}

How can we do that with standalone components? The solution is to use the ENVIRONMENT_INITIALIZER token.

const routes: Routes = [
  {
    path: '',
    pathMatch: 'full',
      component: HomeComponent
    providers:[
      {
        provide: ENVIRONMENT_INITIALIZER,
        multi: true,
        useValue: () => console.log("You can run something right here too")
      }
    ]
  }
]

This token allows us to provide a setup function that will run before the environment is initialized.

If we want it to run when we navigate to a route, we can provide this token using route providers.

This has the same effect as our previous solution using NgModule constructors and has the added benefit of being more explicit.

Typed Forms

Another long-awaited feature of Angular 14 is typed forms.

Before version 14, form values were typed as any. This means that we lose all the awesome type-safety of TypeScript.

  const control = new FormControl(""),
    control.value
    //=> control.value: any

By the way, there is a type-safe way of saying that you don't know the type of something. If you're interested in that, check out this one minute video explaining the differences between any and unknown.

Anyway, we don't have that problem anymore. Because Angular 14 has strict types for forms. So if a FormControl deals with a string, the value will be typed as a string instead of any.

const control = new FormControl(""),
control.value
//=> control.value: string | null

The `inject()` Function

Now, this is the most interesting feature to me.

Angular 14 introduces the inject() function. And it looks very much like React hooks. It gives us a universe of possibilities to reuse our code, the most relevant being that we can now create reusable functions which use dependency injection internally.

export function getPosts() {
  const http = inject(HttpClient);
  return http.get('/api/getPosts');
}

export class HomeComponent {
  readonly posts = getPosts();
}

If you're as interested n functional programming as I am, you know that means a lot! But as Uncle Ben has once said:

"With great power comes great responsibility”

This creates implicit dependencies in your functions. I expect my function dependencies to be explicitly declared in the function arguments. So if I see a function with no arguments, I imagine it to have no dependencies. But now, we can create functions that seem pure but inject a lot of dependencies internally, making them harder to test and more coupled to the Angular framework.

A good solution is to follow the same convention that we have on React, which is to prefix those functions with "use". So that way, you can easily identify functions that use inject() internally.

export function useGetPosts() {
  const http = inject(HttpClient);
  return http.get('/api/getPosts');
}

export class HomeComponent {
  readonly posts = useGetPosts();
}

Set Page title from the route

One common task in web applications is changing the page title on each route.

In Angular, this used to be a very manual process, but now, we can simply define the page title in the route definition.

export const routes: Routes = [
  {
    path: '',
    component: HomeComponent,
    title: 'Home',
    pathMatch: 'full'
  }
];

But I know what you're thinking:

"Lucas, I can't set the title in the route definition because my title is not static, it depends on something I get from my API".

Don't worry. Angular 14 got you covered.

If you need to customize the title dynamically, you can do so by extending the TitleStrategy class from the @angular/router, and providing your new, custom title strategy instead of the default one.

@Injectable({ providedIn: 'root' })
export class PageTitleStrategy extends TitleStrategy {
  constructor(@Inject(Title) private title: Title) {
    super();
  }

  override updateTitle(routerState: RouterStateSnapshot) {
    const title = this.buildTitle(routerState);
    if (title !== undefined) {
      this.title.setTitle(`CompanyName | ${title}`);
    } else {
      this.title.setTitle(`CompanyName | Page without title`);
    }
  }
}

export const routes: Routes = [
  {
    path: '',
    component: HomeComponent,
    title: 'Home',
    pathMatch: 'full'
  }
];

bootstrapApplication(AppComponent, {
  providers: [
    importProvidersFrom(RouterModule.forRoot(routes)),
    { provide: TitleStrategy, useClass: PageTitleStrategy }
  ]
});

Angular CLI Autocomplete

Another nice little thing is that we now have autocomplete in the Angular CLI.

Just type ng on your terminal and press TAB to let the Angular CLI either autocomplete your command or give you some help.

> ng se
            //=> If you press TAB here, the CLI will complete

> ng serve

> ng
        //=> If you press TAB here, the CLI will show a list of commands

> ng
    add           -- Adds support for an external library to your project.
    analytics     -- Configures the gathering of Angular CLI usage metrics.
    build         -- Compiles an Angular application or library into an outpu...
    cache         -- Configure persistent disk cache and retrieve cache sta...
    ...

Activating the CLI autocomplete

To activate it, you must run the ng completion command and confirm that you want to enable the autocomplete by typing Yes.

> ng completion

? Would you like to enable autocompletion? This will set up your terminal so pressing
TAB while typing Angular CLI commands will show possible options and autocomplete arguments.
(Enabling autocompletion will modify configuration files in your home directory.)

> Yes

Finally, just restart your terminal to have autocomplete enabled.

Optional injectors in Embedded Views

Last but not least, we can now pass optional injectors in embedded views. In the past, we had to use other APIs to do that, such as the ngComponentOutlet.

@Directive({ selector: '[foo]' })
export class FooDirective implements OnInit {
  constructor(
    private vcr: ViewContainerRef,
    private templateRef: TemplateRef<unknown>
  ) {}

  ngOnInit(): void {
    this.vcr.createEmbeddedView(
      this.templateRef,
      {}, // context
      {
        injector: Injector.create({
          // pass an injector :)
          providers: [
            {
              provide: 'foo',
              useValue: 'bar'
            }
          ]
        })
      }
    );
  }
}

Don't Stop Here

These were the most relevant changes in Angular 14, in my opinion. If you want to see all changes, you can do so by checking out the references in the description.

If you want to dive deeper into the Angular framework, consider subscribing to our newsletter at lucaspaganini.com. It's spam-free. We keep the emails few and valuable.

And if your company is looking for remote web developers, consider contacting my team and me. You can do so at lucaspaganini.com.

As always, references are in the description. Like. Subscribe. Have a great day. And I will see you in the next one.

– Lucas

References

Static, Unit, Integration, and End-to-End Tests Explained

Lucas Paganini — Mon, 11 Jul 2022 12:42:38 +0000

An exploration of the four major categories of software testing

Spoiler

There are hundreds of different categories of software tests, such as performance tests, functional tests, visual tests, usability tests, and a bunch of others. But out of all these categories, there are four that keep showing up in most projects. They are:

Static tests
Unit tests
Integration tests
End-to-end tests

In this article, we'll go over each of these four most popular categories, so you'll be able to understand their differences and decide which ones you should use in your project.

Spoiler alert: you should be using all of them.

Introduction - What is Software Testing

You can follow the code examples in this article by cloning this public Github repository.

First things first: What is software testing?

Software testing is the process of evaluating software to make sure it avoids regressions and doesn't introduce new bugs. In other words, it's just making sure the software does what it's supposed to do.

There are many ways of doing that. If you want to know all of them, you can check out the references at the end. In this article, we'll explore the four most popular options:

Static tests
Unit tests
Integration tests
End-to-end tests

Static Tests

A static test means that we are testing code without executing it. That's why it's called static.

We can use this to catch typos, type errors, and a lot of other nits. Here are some examples of static tests:

Linting

Linting is the process of checking your source code to enforce stylistic conventions and safety measures.

This is done using a lint tool, also known as linter. Linters are available for most languages. Some renowned linters are ESLint, CSSLint, and Pylint.

The following is an example of how a rule from ESlint would work.

var someFunction = () => {
  //=> 🚨 ESLINT (no-var): Unexpected var, use let or const instead
  console.log('someFunction');
};

In this example, we're using the ESLint no-var rule to enforce the usage of let and const statements instead of var statements. So ESLint is statically analyzing our code without executing it to ensure we're not using var. But since we are using var, ESLint is yelling at us.

This is just one simple example of a linting check, but linters are way more powerful than that. They can check a thousand different rules, and you can also write your own custom rules, if necessary.

You can even have auto-fix for some linting rules, such as automatically replacing var statements with let or const statements.

Another exciting thing that you can do is create a base linter configuration, and then you can reuse that configuration in all your projects. Many companies do that. Facebook, Airbnb, and others have created their own style conventions and linting configurations that enforce those style conventions. Then they reuse those linting rules for their projects.

Type checking

In programming languages, we have strong and weak type systems. When the type system is strong, the compiler warns you in the event of typos and errors. But when the type system is weak, like in JavaScript, some mistakes are hard to detect.

An example of a strong type language is TypeScript. In TypeScript, if you have a function that expects numbers as its arguments, TypeScript won't let you give it a string. It will make sure that you give it a number.

const multiply = (a: number, b: number): number => {
  return a * b;
};

multiply('1', 2);
//=> ⚠️ COMPILER ERROR: Argument of type 'string' is not assignable to parameter of type 'number'.

But the same code in JavaScript won't give you any warnings because you can't set parameter types in JavaScript. Since you can't tell JavaScript that a function expects numbers, it will have no problem accepting strings.

Sometimes that will be fine, and your code will indeed work properly. In other times… things might behave unexpectedly.

const multiply = (a, b) => {
  return a * b;
};

multiply('1', 2);
//=> 2

multiply('hello', 2);
//=> NaN

Static code analysis

Finally, other tools help ensure code quality by analyzing your code and providing valuable insights. Suites like SonarQube, PhpMetrics, or SpotBugs, can provide metrics such as vulnerability reports, testing coverage reports, and feedback about technical debt. These checks are called static code analysis.

Besides type-checking, TypeScript is also able to do some static code analysis. For example, it can detect misuse of the delete operator.

const x = 1;
delete x;
//=> ⚠️ COMPILER ERROR: The operand of a 'delete' operator must be a property reference

Here, TypeScript warns us not to use the delete operator on a variable.

This is different than type-checking. In this case, TypeScript sees that you're making a mistake, but this mistake is not based on a type-check. It's based on how the delete operator was meant to be used. That's why this example fits into the static analysis category, not the type-checking category.

Other static tests

Besides the examples above, there are many other types of static tests, such as:

Informal Reviews
Walkthroughs
Technical Reviews
Inspections

The thing is, all of these practices involve analyzing your code without executing it.

Unit Tests

Unit tests involve testing the smallest units of your code. A "unit" is usually just a function in functional programming or a class in object-oriented programming, but it can be more than that. At the end of the day, you decide what a "unit" means in the context of your project.

Let’s see a simple example of a unit test.

export const sum = (a, b) => {
  return a + b;
};

Given a function called sum, that takes two numbers and returns their sum. We could write some unit tests, for example:

Calling sum() with 1 and 2 should return 3
Calling sum() with -3 and 10 should return 7

That's how the code would look like in a real unit test:

import { sum } from './sum.js';

describe('sum()', () => {
  it('should sum two positive numbers', () => {
    const actual = sum(1, 2);
    const expected = 3;
    expect(actual).toEqual(expected);
  });

  it('should sum positive and negative numbers', () => {
    const actual = sum(-3, 10);
    const expected = 7;
    expect(actual).toEqual(expected);
  });
});

Now that we have written our unit tests, we can run them using a test runner, such as Jasmine or Jest.

> npx jasmine sum.spec.js

Started
Jasmine started

  sum()
    ✓ should sum two positive numbers
    ✓ should sum positive and negative numbers

2 specs, 0 failures
Finished in 0.011 seconds
Executed 2 of 2 specs SUCCESS in 0.011 sec.

Integration Tests

While unit testing is about testing an individual unit in isolation. Integration testing is about testing that a combination of units can work together.

To illustrate, let’s say that we have a function called showUserName that returns the name of a user. But this function uses another function called findUserById to actually find this user.

const USERS = [
  { id: 1, name: 'John' },
  { id: 2, name: 'Jane' },
  { id: 3, name: 'Joe' }
];

export const findUserById = (id) => {
  return USERS.find((user) => user.id === id);
};

export const showUserName = (userId) => {
  const userName = findUserById(userId).name;
  return userName;
};

An integration test for these two modules would look like this:

import { showUserName } from './show-user-name.js';

describe('Integration between showUserName() and findUserById()', () => {
  it('should return the correct user name', () => {
    const name1 = showUserName(1);
    expect(name1).toEqual('John');

    const name2 = showUserName(2);
    expect(name2).toEqual('Jane');

    const name3 = showUserName(3);
    expect(name3).toEqual('Joe');
  });
});

And just like our unit test, we can run our integration test with Jasmine.

> npx jasmine user.spec.js

Started
Jasmine started

  Integration between showUserName() and findUserById()
    ✓ should return the correct user name

1 spec, 0 failures
Finished in 0.006 seconds
Executed 1 of 1 spec SUCCESS in 0.006 sec.

This is a simple example. As I said before, you define what a "unit" means. We can get way more complicated than that. We could write integration tests that simulate HTTP requests to a server. But you get the idea, we just want to make sure that the units can work together.

End-to-End Tests

Now let's get out of our code editor and picture ourselves as real users.

A real user won't mind if we pass the wrong parameter to a function, or if we're receiving the correct data from an API call. The user is only interested in what he can actually see and interact with. And for that, we have end-to-end tests, also known as e2e.

End-to-end tests are all about testing the end-user interaction, but instead of hiring humans, we can use a tool that simulates our users.

An end-to-end test runner will run tests against your entire application using the same interface as your end-users. For example, a web application runs in the browser, so your end-to-end test runner should interact with your application using a browser, just like a real user.

Cypress is a very popular and modern e2e test runner for browsers. Let's see an example e2e test written for Cypress:

describe('End-to-end testing example', () => {
  it('should have the correct title', () => {
    cy.visit('/');
    const fruits = ['Apple', 'Watermelon', 'Banana', 'Peach', 'Orange'];

    cy.get('.title').should('contain', 'Fruits');

    fruits.forEach((fruit) => {
      cy.get('.fruits li').should('contain', fruit);
    });
  });
});

In this case, we want to test that if a user visits our fruit application, he can see the correct title of the website and the correct list of fruits.

Running this test is not as simple as running unit or integration tests because, as I said before, end-to-end tests require your application to be fully running. In our case, our application is a simple file server, and we can start it by running npm start.

> npm start

   ┌───────────────────────────────────────────────────┐
   │                                                   │
   │   Serving!                                        │
   │                                                   │
   │   - Local:            http://localhost:3000       │
   │   - On Your Network:  http://192.168.0.108:3000   │
   │                                                   │
   │   Copied local address to clipboard!              │
   │                                                   │
   └───────────────────────────────────────────────────┘

Now that our application is alive, we can run our end-to-end tests against it. Talking specifically about Cypress, there are two ways of running our tests:

Using the Cypress CLI
Using the Cypress GUI

Running the tests with the Cypress CLI is very similar to how we've been doing things so far. You simply execute cypress run, and it will run the tests and show the results on your terminal.

> npx cypress run

====================================================================================================

  (Run Starting)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Cypress:        9.6.0                                                                          │
  │ Browser:        Electron 94 (headless)                                                         │
  │ Node Version:   v16.14.0 (/Users/lucas/.nvm/versions/node/v16.14.0/bin/node)                   │
  │ Specs:          1 found (fruits.spec.js)                                                       │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

────────────────────────────────────────────────────────────────────────────────────────────────────

  Running:  fruits.spec.js

  End-to-end testing example
    ✓ should have the correct title (200ms)

  1 passing (243ms)

  (Results)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Tests:        1                                                                                │
  │ Passing:      1                                                                                │
  │ Failing:      0                                                                                │
  │ Pending:      0                                                                                │
  │ Skipped:      0                                                                                │
  │ Screenshots:  0                                                                                │
  │ Video:        true                                                                             │
  │ Duration:     0 seconds                                                                        │
  │ Spec Ran:     fruits.spec.js                                                                   │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

  (Video)

  -  Started processing:  Compressing to 32 CRF
  -  Finished processing: /Users/lucas/Downloads/type-of-tests-master/end-to-end-test    (0 seconds)
                          s/cypress/videos/fruits.spec.js.mp4

====================================================================================================

  (Run Finished)

       Spec                                              Tests  Passing  Failing  Pending  Skipped
  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ ✔  fruits.spec.js                           236ms        1        1        -        -        - │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘
    ✔  All specs passed!                        236ms        1        1        -        -        -

But hey, if it were a real human running this test, you'd be able to see the person opening Google Chrome and clicking around. And guess what? Cypress allows you to have a similar experience!

Running cypress open will open a Cypress window. Then you can click on the fruits.spec.ts file and see your browser running your test, controlled by Cypress.

Pretty cool, right?

It's so cool that you might think that it's a good idea to forget about the other types of tests and just write end-to-end tests. And hey, I'm not gonna lie, that can work. But…

As you may have noticed, end-to-end tests take waaaay longer than unit and integration tests. This simple test took 236ms using the Cypress CLI. Imagine hundreds of these. You will quickly get into a state where it takes an hour to run all your e2e tests.

To work around that, most end-to-end test runners allow you to throw money at the problem and run your tests in parallel. But it will never be as fast as running unit and integration tests. This means that your developers will be annoyed at how long it takes, and they will eventually stop running the tests locally.

Also, end-to-end tests require all the setup of actually running your whole application. Which is yet another barrier for your developers.

Verdict

So here's my personal verdict, and you can ignore it if you disagree:

I think we should have strict style conventions and use static tests to enforce them. This will save hours debating whether a new project should use tabs or spaces.
I think we should have fast unit and integration tests that run every time we modify a file. That way, we can have quick feedback if our code breaks something.
And lastly, I think we should have end-to-end tests, particularly for the primary features of our application. No matter how many unit and integration tests I have, end-to-end tests are necessary. Personally, I would not feel confident deploying an application without running some end-to-end tests first.

Don't Stop Here

If you want to dive deeper into software testing or the technologies used in this article, such as JavaScript, TypeScript, and Cypress, consider subscribing to our newsletter. It's spam-free. We keep the emails few and valuable. If you prefer to watch our content, we also have a YouTube channel that you can subscribe to.

And if your company is looking for remote web developers, consider contacting my team and me. You can do so through email, Twitter, or Instagram.

Have a great day!

– Lucas

References

Narrowing Library

Lucas Paganini — Mon, 20 Jun 2022 09:53:21 +0000

TypeScript Narrowing #8

See this and many other articles at lucaspaganini.com

Hello, welcome to the last article of our TypeScript Narrowing series!

Today, I'll show you an open sourced library that I wrote using the same techniques discussed in our previous articles. This library is by no means rigid to anyone's workflow, on the contrary, I made it with the intention of it being valuable to anyone working on a TypeScript codebase.

I'm Lucas Paganini, and on this website, we release web development tutorials. Subscribe if you're interested in that.

Installing and Target Audience

Before we talk about what's inside, you should know how to install it and who should install it.

I made this library available on NPM, to add it to your codebase, simply run npm install @lucaspaganini/ts.

Now, regarding who should install it, I see this library as "Lodash for TypeScript". It provides you with flexible and type safe utilities that make your codebase cleaner. Also, everything is isolated, so you can install it and only import the things that you actually want to use.

That said, I truly believe that this library is useful for anyone who's working on a TypeScript codebase. Frontend, backend, whatever... If you're using TypeScript, you'll benefit from having those utilities.

Currently Available Modules

Without further ado, let's explore what's currently available in the library.

👉 I say "currently available" because it's a living thing. Over time, we will add more to it.

So far, our library has 3 modules:

Core
Assertions
Predicates

Core Module

Let's start with the core module.

The core module contains those 6 utilities:

Mutable
NonNullableProperties
ObjectValues
PickPropertyByType
PickByType
makeConstraint

Mutable is the opposite of the native Readonly type. It converts the readonly properties of a type into regular mutable properties.

type Mutable<T> = { -readonly [P in keyof T]: T[P] }

Mutable<ReadonlyArray<number>>
//=> Array<number>

Mutable<{ readonly a: string }>
//=> { a: string }

NonNullableProperties is similar, it converts all the properties of a type into non-nullable properties.

type NonNullableProperties<T> =
  { [P in keyof Required<T>]: NonNullable<T[P]> }

NonNullableProperties<{ a: string | null }>
//=> { a: string }

NonNullableProperties<{ b?: number }>
//=> { b: number }

NonNullableProperties<{ c: Date | undefined }>
//=> { c: Date }

Then we have ObjectValues, which returns a union type of the types of all the properties in an object. So if your object has three properties, being them a string, a number and a Date. ObjectValues will give you the string | number | Date type.

👉 I can't tell you how useful that is.

type ObjectValues<O> = O[keyof O]

ObjectValues<{ a: string ; b: number; c: Date }>
//=> string | number | Date

PickPropertyByType returns the keys of the properties that match the expected type.

Similar to our last example, if we have an object with four properties, one being a string, another being a number and the last two being Dates. We could use PickPropertyByType to get only the properties that are strings. Or the ones that are numbers. Or even the two that are Dates.

type PickPropertyByType<O, T> =
  ObjectValues<{ [P in keyof O]: O[P] extends T ? P : never }>

type Test = { a: string; b: number; c: Date; d: Date }

PickPropertyByType<Test, string>
//=> "a"

PickPropertyByType<Test, number>
//=> "b"

PickPropertyByType<Test, Date>
//=> "c" | "d"

Similarly, PickByType returns an object that only contains the properties that match the expected type.

type PickByType<O, T> = Pick<O, PickPropertyByType<O, T>>

type Test = { a: string; b: number; c: Date; d: Date }

PickByType<Test, string>
//=> { a: string }

PickByType<Test, number>
//=> { b: number }

PickByType<Test, Date>
//=> { c: Date; d: Date }

And last but not least, makeConstraint allows us to set a type constraint and still keep the literal types.

const makeConstraint =
  <T>() =>
  <V extends T>(v: V): typeof v =>
    v;

For example, let's say we have a type called Icon that contains a name and an id. Both properties should be strings.

Then we declare a ReadonlyArray<Icon> with two icons, one with the id "error" and the other with the id "success".

Now, if you try to extract the IconID based on the type of icons, it will be string. But that's too broad. IconID should be "error" | "success".

type Icon = { id: string; name: string };

const icons: ReadonlyArray<Icon> = [
  { id: 'error', name: 'Error, sorry' },
  { id: 'success', name: 'Success, yaaay' }
] as const;

type IconID = typeof icons[number]['id'];
//=> IconID = string

If we remove the casting of icons to ReadonlyArray<Icon>, we get what we want, but then we lose the type safety of icons.

type Icon = { id: string; name: string };

const icons = [
  { id: 'error', name: 'Error, sorry' },
  { id: 'success', name: 'Success, yaaay' }
] as const;

type IconID = typeof icons[number]['id'];
//=> IconID = "error" | "success"

type Icon = { id: string; name: string };

const icons = [
  { id: 'error', foo: 'Error, sorry' },
  { id: 'success', bar: 'Success, yaaay' }
] as const;

type IconID = typeof icons[number]['id'];
//=> IconID = "error" | "success"

That's where makeConstraint comes into play.

const makeConstraint =
  <T>() =>
  <V extends T>(v: V): typeof v =>
    v

type Icon = { id: string; name: string }
const iconsConstraint = makeConstraint<ReadonlyArray<Icon>>()

const icons = iconsConstraint([
  { id: 'error', foo: 'Error, sorry' }, //=> Error
  { id: 'success', bar: 'Success, yaaay' }, => Error
] as const)

type IconID = typeof icons[number]['id']
//=> IconID = "error" | "success"

With it, we can make sure that icons is a ReadonlyArray<Icon> but still get its literal readonly types.

const makeConstraint =
  <T>() =>
  <V extends T>(v: V): typeof v =>
    v;

type Icon = { id: string; name: string };
const iconsConstraint = makeConstraint<ReadonlyArray<Icon>>();

const icons = iconsConstraint([
  { id: 'error', name: 'Error, sorry' },
  { id: 'success', name: 'Success, yaaay' }
] as const);

type IconID = typeof icons[number]['id'];
//=> IconID = "error" | "success"

Assertions Module

Cool, now let's get into the assertions module.

This module contains these 4 utilities:

AssertionFunction
UnpackAssertionFunction
assertHasProperties
fromPredicateFunction

An AssertionFunction is exactly what it seems. A function that makes a type assertion.

const assertIsString: AssertionFunction<string> = (v) => {
  if (typeof v !== 'string') throw Error('Not a string');
};

let aaa: number | string;
assertIsString(aaa);
aaa; // <- aaa: string

And UnpackAssertionFunction returns the type asserted by an AssertionFunction.

const assertIsString: AssertionFunction<string> = v => {
  if (typeof v !== 'string') throw Error('Not a string')
}

UnpackAssertionFunction<typeof assertIsString>
//=> string

assertHasProperties asserts that the given value has the given properties, and throws if it doesn't.

👉 To keep things safe, the asserted properties are typed as unknown, check this one-minute video to understand the differences between any and unknown.

let foo: unknown = someUnknownObject;

// Usage
foo.a; // <- Compilation error

assertHasProperties(['a'], foo);
foo.a; // <- foo: { a: unknown }

And the last utility in the assertions module is fromPredicateFunction. It takes a PredicateFunction, which we'll talk about in a second, and returns an AssertionFunction.

Predicates Module

The last module in our library is also the largest. The predicates module contains 11 utilities:

PredicateFunction
UnpackPredicateFunction
UnguardedPredicateFunction
AsyncPredicateFunction
AsyncUnguardedPredicateFunction
makeIsNot
makeIsInstance
makeIsIncluded
makeHasProperties
makeAsyncPredicateFunction
fromAssertionFunction

The first one, PredicateFunction, is a type guard. It takes a value and returns a type predicate.

You may be tempted to call this a "type guard", but as I've mentioned in the sixth article of this series (the one about higher order guards), the "type guard" naming is very specific to TypeScript, and these types of functions have been called "predicate functions" way before TypeScript even existed.

type PredicateFunction<T = any> = (v: unknown) => v is T;

const isString: PredicateFunction<string> = (v): v is string =>
  typeof v === 'string';

let aaa: number | string;
if (isString(aaa)) {
  aaa; // <- aaa: string
}

Similarly to UnpackAssertionFunction, we can use UnpackPredicateFunction to extract the type guarded by a PredicateFunction.

type PredicateFunction<T = any> = (v: unknown) => v is T

const isString: PredicateFunction<string> =
  (v): v is string => typeof v === 'string'

type UnpackPredicateFunction<F extends PredicateFunction> =
  F extends PredicateFunction<infer T> ? T : never

UnpackPredicateFunction<typeof isString>
//=> string

Sometimes we have predicate functions that don't return a type predicate, they just return a regular boolean. For those cases, we have the UnguardedPredicateFunction.

For example, isEqual is an UnguardedPredicateFunction.

type UnguardedPredicateFunction<Params extends Array<any> = Array<any>> = (
  ...args: Params
) => boolean;

const isEqual = (a: number, b: number): boolean => a === b;

Then we have the AsyncPredicateFunction, AsyncUnguardedPredicateFunction and makeAsyncPredicateFunction. I won't go deeper into them because the seventh article of our TypeScript Narrowing series was all about them, so I'm not going to waste your time repeating information haha.

type AsyncPredicateFunction<T = any> = (
  value: unknown
) => Promise<PredicateFunction<T>>;

type AsyncUnguardedPredicateFunction<Params extends Array<any> = Array<any>> = (
  ...args: Params
) => Promise<boolean>;

type MakeAsyncPredicateFunction = {
  <F extends AsyncUnguardedPredicateFunction>(fn: F): (
    ...args: Parameters<F>
  ) => Promise<UnguardedPredicateFunction<Parameters<F>>>;

  <T>(fn: AsyncUnguardedPredicateFunction): AsyncPredicateFunction<T>;
};

makeIsNot was also mentioned previously, in the sixth article. It takes a PredicateFunction and returns the inverted version of it.

const isNumber: PredicateFunction<number> = (v): v is number =>
  typeof v === 'number';
const isNotNumber = makeIsNot(isNumber);

let aaa: number | string | Date;
if (isNotNumber(aaa)) {
  aaa; // -> aaa: string | Date
} else {
  aaa; // -> aaa: number
}

makeIsInstance is new though. It takes a class constructor and returns a PredicateFunction that checks if a value is an instanceof the given class constructor.

const makeIsInstance =
  <C extends new (...args: any) => any>(
    classConstructor: C
  ): PredicateFunction<InstanceType<C>> =>
  (v): v is InstanceType<C> =>
    v instanceof classConstructor;

// The following expressions are equivalent:
const isDate = makeIsInstance(Date);
const isDate = (v: any): v is Date => v instanceof Date;

makeIsIncluded takes an Iterable and returns a PredicateFunction that checks if a value is included in the given iterable.

const makeIsIncluded = <T>(iterable: Iterable<T>): PredicateFunction<T> => {
  const set = new Set(iterable);
  return (v: any): v is T => set.has(v);
};

// The following expressions are equivalent:
const abc = ['a', 'b', 'c'];
const isInABC = makeIsIncluded(abc);
const isInABC = (v: any): v is 'a' | 'b' | 'c' => abc.includes(v);

And finally, just like in the assertions module, we have makeHasProperties and fromAssertionFunction.

makeHasProperties takes an array of properties and returns a PredicateFunction that checks if a value has those properties

let foo: unknown = someUnknownObject;

// Usage
foo.a; // <- Compilation error

const hasPropA = makeHasProperties(['a']);
if (hasPropA(foo)) {
  foo.a; // <- foo: { a: unknown }
}

And fromAssertionFunction takes an AssertionFunction and returns a PredicateFunction.

type Assert1 = (v: unknown) => asserts v is 1;
const assert1: Assert1 = (v: unknown): asserts v is 1 => {
  if (v !== 1) throw Error('');
};

const is1 = fromAssertionFunction(assert1);

declare const aaa: 1 | 2 | 3;
if (is1(aaa)) {
  // <- aaa: 1
} else {
  // <- aaa: 2 | 3
}

Series Outro

It's the end, but don't close the article yet, I have some things to say.

This is the last article of our TypeScript narrowing series. The first series I did here and on YouTube.

I'm super happy with the quality that we were able to put out, but I also have big dreams. I want to make things crazy better! And that's why me and my team are building a platform for interactive learning experiences.

Imagine consuming my content and in the middle of it there's a mini-game for you, or a 3D animation, or a quick quiz to consolidate your knowledge. You get the idea.

And all that, available in many languages. We currently offer our content in English and Portuguese. But I also want to offer it in Spanish, German, French, and so many others!

For now, we're releasing all that content for free, but I think it's obvious to say that we'll eventually have paid courses, and I want them to be f** awesome! Like, deliver *unbelievable* value!

So sure, if you haven't yet, I highly encourage you to subscribe to the newsletter. Your support is highly appreciated.

Thank you so much for sticking with me, I hope you enjoyed it, and I hope this is only the beginning of a long journey on YouTube and content creation in general. 🙂

Conclusion

As always, references are below.

And if your company is looking for remote web developers, please consider contacting me and my team on lucaspaganini.com.

Until then, have a great day, and I’ll see you in the next one.

References

TypeScript Utilities Library - @lucaspaganini/tsGithub Repository

Asynchronous type guards

Lucas Paganini — Tue, 14 Jun 2022 12:15:21 +0000

TypeScript Narrowing #7

See this and many other articles at lucaspaganini.com

Hey, welcome to part 7 of our TypeScript narrowing series.

Before we start, let me say this: It is recommended that you read the articles of this series in sequence, but you don't really need to read all of them to understand this one. What you do need, is to read part 3 and 6, at least. Otherwise, you'll probably feel lost here. Ok?

Today, we’ll talk about a highly requested feature in TypeScript: asynchronous type guards!

We just have one small problem… it’s still just a feature request, there’s no official support for asynchronous type guards yet.

But as developers, we can’t just wait for someone else to fix our problems, sometimes (most times) we need to find a solution ourselves, and with the tools we currently have available.

And that’s exactly what we’re going to do. I’ll show you the cleanest workaround for asynchronous type guards that I came up with. It is also a solution that will be easy to refactor once we do get support for asynchronous type guards in TypeScript.

If you have a different solution, please, leave a comment and we can discuss it.

I'm Lucas Paganini, and in this blog, we release web development tutorials. Subscribe if you're interested in that.

The Goal

In an ideal world, we would be writing asynchronous functions that return a type predicate wrapped in a Promise.

const isStringAsync =
  async (value: unknown): Promise<value is string> =>
    typeof value === "string"

We can’t do that yet, but we can strive to get as close to it as possible. So, let's look for a workaround that is close to this ideal implementation.

Also, you might be wondering why would we ever asynchronously check if a value is a string. Well, I too wonder that. Why would we ever do that?

The thing is, I have a real world use case where asynchronous type guards would be useful. And I’ll show you that scenario. But I want us to first understand our implementation of asynchronous type guards. So let’s stick with our fictional isStringAsync function for now.

The Workaround

We can't currently return a type predicate wrapped in a Promise, but we can return a boolean wrapped in a Promise.

const isStringAsync =
  async (value: unknown): Promise<value is string> =>
    typeof value === "string"

const isStringAsync = async (value: unknown): Promise<boolean> =>
  typeof value === 'string';

Now, as you might have guessed, that boolean means nothing to TypeScript. It performs no type narrowing in our variable.

const isStringAsync = async (value: unknown): Promise<boolean> =>
  typeof value === 'string';

const aaa = 1 as number | string | Date;
isStringAsync(aaa).then((isString) => {
  if (isString) {
    aaa; // <- aaa: string | number | Date
  } else {
    aaa; // <- aaa: string | number | Date
  }
});

That's sad. It seems like we can only have synchronous type guards...

But wait. In the last article, we learned that we can have functions that create new type guards. So maybe we could have a function that asynchronously creates a synchronous type guard.

See, instead of returning the Promise of a type predicate, which we can't do yet.

const isStringAsync =
  async (value: unknown): Promise<value is string> =>
    typeof value === "string"

We could return the Promise of a function that returns a type predicate.

const isStringAsync =
  async (value: unknown): Promise<(v: unknown) => v is string> =>
  (v): v is string =>
    typeof value === 'string';

And it actually works!

const isStringAsync =
  async (value: unknown): Promise<(v: unknown) => v is string> =>
  (v): v is string =>
    typeof value === 'string';

const aaa = 1 as number | string | Date;
isStringAsync(aaa).then((isString) => {
  if (isString(aaa)) {
    aaa; // <- aaa: string
  } else {
    aaa; // <- aaa: number | Date
  }
});

And it's so close to the ideal scenario, that it will be very easy to refactor our code once we do get native support for asynchronous type guards.

const isStringAsync =
  async (value: unknown): Promise<v is string> =>
    typeof value === "string"

const aaa = 1 as number | string | Date
isStringAsync(aaa).then(isString => {
  if (isString) {
    aaa // <- aaa: string
  } else {
    aaa // <- aaa: number | Date
  }
})

Motivations for Asynchronous Type Guards

Awesome! Now that we got the implementation, let's discuss a real world scenario where it would really be beneficial for us to have asynchronous type guards. Because checking if a value is a string asynchronously, is not a good example.

I'll give you an example inspired by the one that Dominik Głodek gave when he made the feature request for asynchronous type guards:

You're writing an API endpoint that receives data to create a user. The user data consists of an email and a password.

interface User {
  email: string;
  password: string;
}

You can only save users to the database if they are valid. For a user to be valid, it needs to meet 2 criteria:

The password should have at least 8 characters
The email cannot already belong to another user

The first check could be done synchronously, so let's start with that. We will create an assertion function called validateUser that checks that our object complies with the User interface and with the password validation.

type ValidateUser = (value: unknown) => asserts value is User;

const validateUser: ValidateUser = (value) => {
  assertHasProperties(['email', 'password'], value);
  assertIsString(value.email);
  assertIsString(value.password);

  // 1. The password should have at least 8 characters
  if (value.password.length < 8) throw Error('Password is too short');
};

👉 If you don't know what an assertion function is, we have a full article on this topic. It's the fifth article of this series. I'll leave a link for it in the references.

Before we add our asynchronous validation to make sure the user email doesn't already belong to another user, let's see what would happen if we tried to use our assertion function as it is right now.

const saveUserToDatabase =
  async (user: User): Promise<void> => { ... }

type ValidateUser =
  (value: unknown) =>
    asserts value is User
const validateUser: ValidateUser = value => { ... }

let user: unknown
validateUser(user)
await saveUserToDatabase(user)

As you can see, TypeScript thinks it's all good. There are no compilation errors. saveUserToDatabase is expecting a User and that's what it's getting. But it doesn't know that this User has not been fully validated yet.

Actually, TypeScript would think it's all good even if we did not validate the password length. In short, TypeScript is only verifying that our value complies with the User interface, it's not verifying if it passes the validation criteria.

Could we somehow tell TypeScript when a value not only complies with the User interface but is also a fully validated user? Well... yeah. We can.

We can create a secret property to indicate that the password length has been validated and another to indicate that the email doesn't belong to another user. Also, we can have a union type, called ValidatedUser which is equal to an User that has both validations.

type PasswordValidated<T> = T & {
  readonly __passwordValidated__: unique symbol;
};

type UniqueEmailValidated<T> = T & {
  readonly __uniqueEmailValidated__: unique symbol;
};

type ValidatedUser = PasswordValidated<User> & UniqueEmailValidated<User>;

With that in place, we can change the signature of validateUser to assert that the value is not just a User, but a PasswordValidated<User>.

type ValidateUser =
  (value: unknown) =>
    asserts value is User
const validateUser: ValidateUser = value => { ... }

type ValidateUser =
  (value: unknown) =>
    asserts value is PasswordValidated<User>
const validateUser: ValidateUser = value => { ... }

And we can also change the signature of saveUserToDatabase to make it only accept users that have already been fully validated.

type ValidateUser =
  (value: unknown) =>
    asserts value is PasswordValidated<User>
const validateUser: ValidateUser = value => { ... }

const saveUserToDatabase =
  async (validUser: ValidatedUser): Promise<void> => { ... }

With that structure in place, I'm weirdly happy to say that our code would NOT compile.

type PasswordValidated<T> = T & {
  readonly __passwordValidated__: unique symbol
}

type UniqueEmailValidated<T> = T & {
  readonly __uniqueEmailValidated__: unique symbol
}

type ValidatedUser = PasswordValidated<User> & UniqueEmailValidated<User>

const validateUser =
  (value: User): asserts value is PasswordValidated<User> => { ... }

const saveUserToDatabase =
  async (validUser: ValidatedUser): Promise<void> => { ... }

let user: unknown
validateUser(user)
await saveUserToDatabase(user)
// Compilation error: Argument of type 'PasswordValidated<User>' is not assignable to parameter of type 'ValidatedUser'.

Yaaaay 🎉🎉🎉

For it to compile again, we need to create an asynchronous assertion function using the same trick that we used for asynchronous type guards.

type ValidateUser = (
  value: unknown
) => asserts value is PasswordValidated<User> & UniqueEmailValidated<User>;

const validateUserAsync = async (value: unknown): Promise<ValidateUser> => {
  // If we throw an error, save it to throw later, in the assertion function
  let errorToThrow: Error | null = null;

  try {
    assertHasProperties(['email', 'password'], value);
    assertIsString(value.email);
    assertIsString(value.password);

    // 1. The password should have at least 8 characters
    if (value.password.length < 8) throw Error('Password is too short');

    // 2. The email cannot already belong to another user
    if (await emailIsAlreadyTaken(value.email))
      throw Error('Email is already taken');
  } catch (error) {
    errorToThrow = error;
  }

  return (v) => {
    if (errorToThrow) throw errorToThrow;
  };
};

Ok, I think we're good now. Calling validateUserAsync returns the Promise of a synchronous assertion function. Which we then use to assert that the value is a ValidatedUser.

type PasswordValidated<T> = T & {
  readonly __passwordValidated__: unique symbol
}

type UniqueEmailValidated<T> = T & {
  readonly __uniqueEmailValidated__: unique symbol
}

type ValidatedUser = PasswordValidated<User> & UniqueEmailValidated<User>

type ValidateUser =
  (value: unknown) =>
    asserts value is
      PasswordValidated<User> & UniqueEmailValidated<User>
const validateUserAsync =
  async (value: unknown): Promise<ValidateUser> => { ... }

const saveUserToDatabase =
  async (validUser: ValidatedUser): Promise<void> => { ... }

let user: unknown
const validateUser: ValidateUser = await validateUserAsync(user)
validateUser(user)
await saveUserToDatabase(user)

Cool, now we're protecting ourselves from performing database operations with unvalidated resources. That's a real world use case for asynchronous type guards and a whole bunch of advanced TypeScript madness.

`makeAsyncPredicateFunction`

And you know what? I love you. So I went ahead and made our lives even easier.

I made an asynchronous higher order guard that creates asynchronous type guards for us. If you choose to use my utility function, it will be even easier to create asynchronous guards and refactor them once we get native support for them in TypeScript.

import { makeAsyncPredicateFunction } from '@lucaspaganini/ts';

const isStringAsync = makeAsyncPredicateFunction<string>(
  async (value) => typeof value === 'string'
);

const aaa = 1 as number | string | Date;
isStringAsync(aaa).then((isString) => {
  if (isString(aaa)) {
    aaa; // <- aaa: string
  } else {
    aaa; // <- aaa: number | Date
  }
});

It works on Node and Browsers, you can install it with npm install @lucaspaganini/ts. But that library is a topic for the next article, so stay tuned.

Conclusion

References are in the description.

I made a comment in the feature request for asynchronous type guards, explaining the workaround I came up with. If you don't mind, it would be great if you give a thumbs up to the feature request and to my comment, to give them more traction. The link for it is also in the references.

If you enjoyed the content, you know what to do.

And if your company is looking for remote web developers, consider contacting me and my team on lucaspaganini.com.

In the next article, we'll talk about that library. And I'm planning it to be the last article of this series, so stick around, I think it'll be worth it.

Until then, have a great day, and I’ll see you soon.

References

Higher Order Guards (Functions)

Lucas Paganini — Tue, 14 Jun 2022 12:14:59 +0000

TypeScript Narrowing #6

See this and many other articles at lucaspaganini.com

Oofff, it’s part 6 already! I wonder how many of you are reading this since the beginning.

Today we'll grab a pattern from the functional programming world known as "Higher Order Functions" and use it to create functions that receive functions and return new functions.

function f1() {}

function f1(f2: Function) {}

But we won't stop there. We won't just return any new functions, more precisely, we will return new custom type guards! So, I'm calling those guard creation functions "Higher Order Guards".

const makeIsNot = fn => ✨magic✨

As you'll soon find out, that will open the door for new possibilities of reusing our code.

const makeIsNot = fn => ✨magic✨

const isNotString = makeIsNot(isString)

let aaa = 'abc' as  string | number | boolean
if (isNotString(aaa)) {
  aaa // <- aaa: number | boolean
} else {
  aaa // <- aaa: string
}

I'm Lucas Paganini, and in this blog, we release web development tutorials. Subscribe if you're interested in that.

Higher Order Functions

The theoretical description of a higher order function is a tongue twister: a function that receives a function and returns another function. So let me show it to you in practice, and you'll see that it's not as complex as it sounds.

Let's say we have a lot of custom type guards, and now we want inverted versions of them.

We already have isString, now we want isNotString.
We already have isNumber, now we want isNotNumber.
You get the idea...

We did something very similar in the end of our third article, when we wrote a guard for truthy values that works by excluding falsy values.

type Truthy<T> = Exclude<T, Falsy>;

const isTruthy = <T extends unknown>(value: T): value is Truthy<T> =>
  value == true;

// Test
let x: null | string | 0;
if (isTruthy(x)) {
  x.trim(); // <- x: string
}

We can apply the same technique to create our inverted type guards. That's how they would look like:

const isNotString = <V extends unknown>(
  value: V
): value is Exclude<V, string> => isString(value) === false;

const isNotNumber = <V extends unknown>(
  value: V
): value is Exclude<V, number> => isNumber(value) === false;

But writing those inverted guards manually is tedious and repetitive. I bet you can see a pattern in them: all we need to create an inverted guard, is the custom type guard that will be inverted.

In other words: the only difference between isNotString and isNotNumber, is that while one uses the isString guard, the other uses the isNumber guard.

Higher Order Guards

Could we stop repeating ourselves and create a function that accepts a type guard as an argument and returns the inverted version of the given type guard?

const makeIsNot = (fn) => (v) => !fn(v);

const isNotString = makeIsNot(isString);

Hell yeah we can! Let's create it now!

I have a personal convention of prefixing functions with the word make when they return new functions. So, it makes sense to me to call our function makeIsNot, since it makes the is not version of a type guard.

`makeIsNot` Implementation

The function implementation alone, is already a bit tricky, so I'll navigate it with you before we get into the TypeScript signature.

Let's use isNotString as an example.

const makeIsNot = (fn) => (v) => !fn(v);

const isNotString = makeIsNot(isString);

Calling makeIsNot with isString, returns a function that receives one argument (called v), and returns the inverted return of calling isString with v.

const makeIsNot = (fn) => (v) => !fn(v);

const isNotString = makeIsNot(isString);

const makeIsNot = (fn) => (v) => !fn(v);

const isNotString = (
  (fn) => (v) =>
    !fn(v)
)(isString);

The same works for isNotNumber. Calling makeIsNot with isNumber, returns a function that receives one argument (called v), and returns the inverted return of calling isNumber with v.

const makeIsNot = (fn) => (v) => !fn(v);

const isNotNumber = makeIsNot(isNumber);

const makeIsNot = (fn) => (v) => !fn(v);

const isNotNumber = (
  (fn) => (v) =>
    !fn(v)
)(isNumber);

`makeIsNot` Signature

All is good and well with the implementation, now, to the type signature of makeIsNot.

type MakeIsNot = <F extends (v: unknown) => v is any>(
  fn: F
) => <V extends Parameters<F>[0] = Parameters<F>[0]>(
  v: V
) => v is Exclude<V, F extends (v: unknown) => v is infer T ? T : never>;

const makeIsNot: MakeIsNot = (fn) => (v) => !fn(v);

Let's break it down and see what can be simplified.

Type Guard Function Type

First, there are two places where we're referring to a function that returns a type predicate (in other words, a custom type guard).

Let's create a type, called TypeGuardFunction, to isolate that type definition and simplify our code a little.

type TypeGuardFunction<T = any> = (v: unknown) => v is T;

type MakeIsNot = <F extends TypeGuardFunction>(
  fn: F
) => <V extends Parameters<F>[0] = Parameters<F>[0]>(
  v: V
) => v is Exclude<V, F extends TypeGuardFunction<infer T> ? T : never>;

const makeIsNot: MakeIsNot = (fn) => (v) => !fn(v);

A little better, right?

Predicate Function Type

Also, even though the naming TypeGuardFunction makes a lot of sense, since it is indeed a type guard function, this name is very specific to TypeScript. And it turns out that functions that receive an argument and return a boolean already had a name before TypeScript even existed. Those functions are known as "Predicate Functions".

So, let's use the name PredicateFunction instead.

type PredicateFunction<T = any> = (v: unknown) => v is T;

type MakeIsNot = <F extends PredicateFunction>(
  fn: F
) => <V extends Parameters<F>[0] = Parameters<F>[0]>(
  v: V
) => v is Exclude<V, F extends PredicateFunction<infer T> ? T : never>;

const makeIsNot: MakeIsNot = (fn) => (v) => !fn(v);

Unpack Predicate Function Type

Also, not that it repeats, but that part where we're inferring the type of the PredicateFunction is kinda ugly to look at. Let's isolate that in a type.

👉 If you're at a lost with the ternary operator and the infer keyword, I have two videos for you. Both are one minute long. One explains conditional types in TypeScript (the ternary operator), and the other explains the infer operator. Their links are in the description.

I have another personal convention which is to use the prefix Unpack when I'm creating a type that infers something. So I'll call it UnpackPredicateFunction.

type PredicateFunction<T = any> = (v: unknown) => v is T;

type UnpackPredicateFunction<F extends PredicateFunction> =
  F extends PredicateFunction<infer T> ? T : never;

type MakeIsNot = <F extends PredicateFunction>(
  fn: F
) => <V extends Parameters<F>[0] = Parameters<F>[0]>(
  v: V
) => v is Exclude<V, UnpackPredicateFunction<F>>;

const makeIsNot: MakeIsNot = (fn) => (v) => !fn(v);

Back to the Signature

Ok... it's not simple. But it is simpler. Let's try to analyze the signature now.

First, we receive an argument, a PredicateFunction called fn;
Then, we return a new function;
This new function receives an argument, called v. Which has the same type of the first parameter of fn;
And that, returns a type predicate saying that v is not of the type guarded by our fn function.

type PredicateFunction<T = any> = (v: unknown) => v is T;

type UnpackPredicateFunction<F extends PredicateFunction> =
  F extends PredicateFunction<infer T> ? T : never;

type MakeIsNot = <F extends PredicateFunction>(
  fn: F
) => <V extends Parameters<F>[0] = Parameters<F>[0]>(
  v: V
) => v is Exclude<V, UnpackPredicateFunction<F>>;

const makeIsNot: MakeIsNot = (fn) => (v) => !fn(v);

Library

There are some limitations to our function. For example, right now, it only works with guards that receive a single argument. Also, it's not tested.

type PredicateFunction<T = any> = (v: unknown) => v is T;

type UnpackPredicateFunction<F extends PredicateFunction> =
  F extends PredicateFunction<infer T> ? T : never;

type MakeIsNot = <F extends PredicateFunction>(
  fn: F
) => <V extends Parameters<F>[0] = Parameters<F>[0]>(
  v: V
) => v is Exclude<V, UnpackPredicateFunction<F>>;

const makeIsNot: MakeIsNot = (fn) => (v) => !fn(v);

const isNotString = makeIsNot(isString);

If you're interested in having makeIsNot in your codebase (and also makeIsInstance, makeIsIncluded, and a lot more), instead of copying the code from this article, a better way is to just install my TypeScript utilities library.

import { makeIsNot } from '@lucaspaganini/ts';

const isNotString = makeIsNot(isString);

import { makeIsNot, makeIsInstance } from '@lucaspaganini/ts';

const isNotString = makeIsNot(isString);
const isArray = makeIsInstance(Array);

import { makeIsNot, makeIsInstance, makeIsIncluded } from '@lucaspaganini/ts';

const isNotString = makeIsNot(isString);
const isArray = makeIsInstance(Array);
const isFamousCat = makeIsIncluded(['Garfield', 'Tom']);

It's open source
Has tests
Documentation
Works on Node and Browsers
It's MIT
And you can easily install it with npm install @lucaspaganini/ts.

npm install @lucaspaganini/ts

We'll talk more about that library in the next article.

Conclusion

Today's content was pretty advanced. I remember how hard it was for me to learn functional programming and advanced TypeScript notations, so we really did our best with the examples and animations to hopefully, give you an easier learning experience than the one I had.

I would love to have a feedback from you. So, please send me a tweet and let us know if you could understand everything, and your questions, if you have any.

References are below. If you enjoyed the content, you know what to do.

And if your company is looking for remote web developers, consider contacting me and my team on lucaspaganini.com.

In the next article, we will use our newly found knowledge to create a workaround for a highly requested feature in TypeScript: asynchronous type guards. Subscribe if you don't want to miss it.

Until then, have a great day, and I’ll see you soon.

References

Assertion Functions or Assertion Guards

Lucas Paganini — Fri, 10 Jun 2022 21:15:09 +0000

TypeScript Narrowing #5

See this and many other articles at lucaspaganini.com

Welcome to the fifth article in our TypeScript narrowing series! Be sure to read the previous ones, if you haven't yet. Their links are in the references.

In this article, I'll show you assertion functions, also known as assertion guards.

I'm Lucas Paganini, and on this website, we release web development tutorials. Subscribe if you're interested in that.

Assertion Functions vs Type Guards

The reason why assertion functions are also known as assertion guards is because of their similarity to type guards.

In our type guard for strings, we return true if the given argument is a string and false if it's not.

const isString = (value: unknown): value is string => typeof value === 'string';

If we wanted an assertion function instead of a type guard, instead of returning either true or false, our function would either return or throw. If it is a string, it returns. If it's not a string, it throws.

function assertIsString(value: unknown): asserts value is string {
  if (typeof value !== 'string') throw Error('value is not a string');
}

If you call a function that throws if your value is not a string, then all the code that comes after it will only run if your value is a string, so TypeScript narrows our type to string.

const x = 'abc' as string | number;
x; // <- x: `string | number`

assertIsString(x);
x; // <- x: `string`

To abstract this explanation: TypeScript uses control flow analysis to narrow our type to what was asserted. In this case, we have asserted that value is a string.

function assertIsString(value: unknown): asserts value is string {
  if (typeof value !== 'string') throw Error('value is not a string');
}

We talk about control flow analysis in the second article of this series, the link for it is in the references.

Early Exits

Now, when and why would you want to use an assertion function instead of a type guard?

Well, the most popular use case for assertion functions is data validation.

Suppose you have a NodeJS server, and you’re writing a handler for user creation.

/** Expected body for POST /api/users */
interface CreatableUser {
  name: string;
  email: string;
  password: string;
}

The first thing you should do in your request handlers is to validate the data. If any of the fields are missing or invalid, you’ll want to throw an error.

function assertIsCreatableUser(value: unknown): asserts value is CreatableUser {
  if (typeof value !== 'object') throw Error('Creatable user is not an object');
  if (value === null) throw Error('Creatable user is null');

  assertHasProps(['name', 'email', 'password'], value);
  assertIsName(value.name);
  assertIsEmail(value.email);
  assertIsPassword(value.password);
}

When you have conditions to check at the beginning of your code, and you refuse to run if those conditions are invalid, that’s called an “early exit” and it’s the perfect scenario for an assertion function!

const userCreationHandler = (req: Request, res: Response): void => {
  try {
    // Validate the data before anything
    const data = req.body
    assertIsCreatableUser(data)

    // Data is valid, create the user
    ...
  } catch (err) {
    // Data is invalid, respond with 400 Bad Request
    const errorMessage =
      err instanceof Error
        ? err.message
        : "Unknown error"
    res.status(400).json({ errors: [{ message: errorMessage }] })
  }
}

If you want to know more about early exits, I have a one-minute video explaining this concept. The link is in the references.

/** Non empty string between 3 and 256 chars */
type Name = string;

function assertIsName(value: unknown): asserts value is Name {
  if (typeof value !== 'string') throw Error('Name is not a string');
  if (value.trim() === '') throw Error('Name is empty');
  if (value.length < 3) throw Error('Name is too short');
  if (value.length > 256) throw Error('Name is too long');
}

Issues with Control Flow Analysis

Maybe you've noticed that I'm using function declarations instead of function expressions. There's a reason for that.

First, knowing the differences between function declarations and functions expressions is very important. I'm sure most of you already know that, but if you don't, it's ok. I'll leave a link in the references for a one-minute video explaining their differences.

So, back to assertion functions. I'm using function declarations because TypeScript has trouble recognizing assertions functions during control flow analysis if they're written as function expressions.

Function declarations work because they're hoisted, so their types are declared previously and TypeScript likes that.

I think that's a bug. But I don't know if they're going to fix this. Currently, they say it's working as intended.

To work around that issue, I've found two alternatives:

Use function declarations

// Alternative 1: Functions Declaration

function assertIsString(value: unknown): asserts value is string {
  if (typeof value !== 'string') throw Error('value is not a string');
}

Use function expressions with predefined types

// Alternative 2: Function Expressions with Predefined Types

// Predefined type
type AssertIsString = (value: unknown) => asserts value is string;

// Function expression with predefined type
const assertIsString: AssertIsString = (value) => {
  if (typeof value !== 'string') throw Error('value is not a string');
};

Function Expressions with Predefined Types

I prefer function expressions, so I'll go with the second alternative.

For that, instead of defining our function signature along with its implementation.

// DON'T: Signature with implementation
const assertIsString = (value: unknown): asserts value is string => {
  if (typeof value !== 'string') throw Error('value is not a string');
};

We'll have to define its signature as an isolated type and cast our function to that type.

// Predefined type
type AssertIsString = (value: unknown) => asserts value is string;

// Function expression with predefined type
const assertIsString: AssertIsString = (value) => {
  if (typeof value !== 'string') throw Error('value is not a string');
};

Here's how it looks like if we wanted to use function expressions for our assertIsName function:

// Predefined type
type AssertIsName = (value: unknown) => asserts value is Name;

// Function expression with predefined type
const assertIsName: AssertIsName = (value) => {
  if (typeof value !== 'string') throw Error('Name is not a string');
  if (value.trim() === '') throw Error('Name is empty');
  if (value.length < 3) throw Error('Name is too short');
  if (value.length > 256) throw Error('Name is too long');
};

And we were also using an assertHasProps function to check that our object has the properties that we expect. Maybe you're curious, so I'm showing it too because I think that function has an interesting signature.

// Predefined type
type AssertHasProps = <Prop extends string>(
  props: ReadonlyArray<Prop>,
  value: object
) => asserts value is Record<Prop, unknown>;

// Function expression with predefined type
const assertHasProps: AssertHasProps = (props, value) => {
  // Only objects have properties
  if (typeof value !== 'object') throw Error(`Value is not an object`);

  // Make sure it's not null
  if (value === null) {
    throw Error('Value is null');
  }

  // Check if it has the expected properties
  for (const prop of props)
    if (prop in value === false) throw Error(`Value doesn't have .${prop}`);
};

I'm also leaving a link to the GitHub issues and PRs related to this if you want to know more.

Assertions without a Type Predicate

Before we wrap this up, I want to show you a different signature for assertion functions:

type Assert = (condition: unknown) => asserts condition;
const assert: Assert = (condition) => {
  if (condition == false) throw 'Invalid assertion';
};

This signature is weird, right? There is no type of predicate, what the hell are we asserting?

This signature means that the condition to check is already a type guard. For example, you could give it a typeof expression, and it would narrow the type accordingly:

const x = 'abc' as string | number;
x; // <- x: `string | number`

assert(typeof x === 'string');
x; // <- x: `string`

Conclusion

Assertion functions are cool, right? People are just not used to them yet.

References are below. If you enjoyed the content, you know what to do.

And if your company is looking for remote web developers, consider contacting me and my team on lucaspaganini.com.

This is not the last article of this series. We have more to come! Until then, have a great day, and I’ll see you in the next one!

References

Discriminated Unions or Tagged Unions Types

Lucas Paganini — Fri, 10 Jun 2022 21:14:42 +0000

TypeScript Narrowing #4

See this and many other articles at lucaspaganini.com

Heeeello and welcome to the fourth article in our TypeScript narrowing series. We're continuing from where we left off, so If you've missed any of the previous articles, I suggest you go back and read them.

In this article, we will cover tagged union types (AKA discriminated unions).

And we have more to come, in future articles:

Assertion guards
Higher-order guards
Narrowing library

I'm Lucas Paganini, and on this site, we release web development tutorials. Subscribe to the newsletter if you're interested in that.

Tagged Union Types (Discriminated Unions)

So, tagged union types... what are they?

It's pretty self-explanatory. They are union types with a tag 😅

For example, you could have a union type called Log that aggregates three interfaces: Warning, Debug, and Information.

type Log = Warning | Debug | Information;

interface Warning {
  text: string;
}

interface Debug {
  message: string;
}

interface Information {
  msg: string;
}

Cool, now we have a union type. To turn that into a tagged union type, we need a common property with literal types between our interfaces. It could be any property name, but to simulate a real-world example, we'll call it .subscribeToTheNewsletter.

This property will serve as an ID for the different types of interfaces that make up the Log type. Every interface will have a different literal type for that property.

type Log = Warning | Debug | Information;

interface Warning {
  subscribeToTheNewsletter: 'like';
  text: string;
}

interface Debug {
  subscribeToTheNewsletter: 'comment';
  message: string;
}

interface Information {
  subscribeToTheNewsletter: 'share';
  msg: string;
}

And that's it. The .subscribeToTheNewsletter property is serving as a tag for the Log type, so it is now a tagged union type.

Discriminated Union Terminology

As I've mentioned before, this is also known as a discriminated union, and our .subscribeToTheNewsletter property is the discriminant property of Log.

To quote from the TypeScript docs: "When every type in a union contains a common property with literal types, TypeScript considers that to be a discriminated union."

From now on, I'll use the "discriminated unions" terminology, instead of "tagged union types" because that's how TypeScript is calling it nowadays, and I want to be consistent with the official terminologies – even though I believe "tagged union types" would be a better name for it.

Type Guards for Discriminated Unions

"Ok Lucas, I got it. But what's the point? What do I get to do with a discriminated union?"

Good question.

What you get with a discriminated union is a type guard for all the possible discriminations of the union type.

For example, if you have a variable called value that is a Log. That means that value could be either a Warning, a Debug or an Information.

let value: Log;

if (isWarning(value)) {
  // Handle the Warning case
} else if (isDebug(value)) {
  // Handle the Debug case
} else if (isInformation(value)) {
  // Handle the Information case
}

const isWarning =
  (value: unknown): value is Warning => { ... }

const isDebug =
  (value: unknown): value is Debug => { ... }

const isInformation =
  (value: unknown): value is Information => { ... }

But instead of creating individual guards for those three interfaces, you could just check the value of the discriminant property.

If .subscribeToTheNewsletter is "like", you know that it's a Warning. If it's "comment", it's a Debug. And if it's "share", it's an Information.

let value: Log;

if (value.subscribeToTheNewsletter === 'like') {
  // Handle the Warning case
} else if (value.subscribeToTheNewsletter === 'comment') {
  // Handle the Debug case
} else if (value.subscribeToTheNewsletter === 'share') {
  // Handle the Information case
}

And you can make your code even clearer by going an extra mile and switching your if statements – got it? 😉 "switching"... "switch"... no? ok...

let value: Log;

switch (value.subscribeToTheNewsletter) {
  case 'like':
  // Handle the Warning case
  case 'comment':
  // Handle the Debug case
  case 'share':
  // Handle the Information case
}

Conclusion

References and links for the previous articles are in the references.

If you enjoyed the content, you know what to do.

And if your company is looking for remote web developers, consider contacting me and my team. You can do so on lucaspaganini.com.

Have a great day, and I'll see you soon.

References

Custom Type Guards

Lucas Paganini — Fri, 10 Jun 2022 21:14:25 +0000

TypeScript Narrowing #3

See this and many other articles at lucaspaganini.com

Hey, welcome to another article in our TypeScript Narrowing series. In this article, I'll explain:

Type predicates
How to create your own guards
How to create a guard by exclusion

This is the third article in our series, if you haven't watched the previous ones, I highly recommend that you do, they lay out solid fundamentals for narrowing. I'll leave a link for them in the references.

I'm Lucas Paganini, and on this site, we release web development tutorials. If that's something you're interested in, leave a like and subscribe to the newsletter.

Type Predicates

In the last article, we explored the fundamental type guard operators. Now I'd like to show you type guard functions.

For example, if you need to check if a variable called value is a string, you could use the typeof operator. But what you could also do, is to create a function called isString() that receives an argument and returns true if the given argument is a string.

const isString = (value: any): boolean => typeof value === 'string';

Remember our formatErrorMessage() function from the last article?

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  if (value instanceof Error) {
    return prefix + value.message;
  }

  // We will never reach here
  throw new Error(`Invalid value type`);
};

interface Warning {
  text: string;
}

Let's remove the typeof operator from it and use isString() instead.

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (isString(value)) {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  if (value instanceof Error) {
    return prefix + value.message;
  }

  // We will never reach here
  throw new Error(`Invalid value type`);
};

interface Warning {
  text: string;
}

It's the same code, we've just isolated the guard in a function, right? No. It breaks. TypeScript is not narrowing the type to string, the guard is not working.

Here's the thing, isString() is returning a boolean and we know what that boolean means.

const isString = (value: any): boolean => typeof value === 'string';

It means that the argument is a string. But TypeScript doesn't know what that boolean means, so let's teach it.

Instead of saying that our function returns a boolean, we need to say that our function returns the answer to the question: "is this argument a string?".

Given that the name of our argument is value, we do that with the following syntax: value is string.

const isString = (value: any): value is string => typeof value === 'string';

Now TypeScript understands that isString() is a type guard and our formatErrorMessage() function compiles correctly.

The return type of our isString() function is not just a boolean anymore, it's a "Type Predicate".

So to make a custom type guard, you just define a function that returns a type predicate.

All type predicates take the form of { parameter } is { Type }.

The `unknown` Type

A quick tip before we continue:

Instead of using the type any in our custom guard parameter, our code would be safer if we used the unknown type.

const isString = (value: unknown): value is string => typeof value === 'string';

I made a one-minute video explaining the differences between any and unknown, the link is in the references.

Custom Guards

Let's exercise our knowledge by converting all the checks in our formatErrorMessage() function to custom guards.

We already have a guard for strings, now we need guards for Warning, Error and falsy types.

`Error` Guard

The guard for Error is pretty straightforward, we just isolate the instanceof operator check in a function.

const isError = (value: unknown): value is Error => value instanceof Error;

`Warning` Guard

But the Warning guard, on the other hand, is not that simple.

TypeScript allowed us to use the in operator because there was a limited amount of types that our value parameter could be, and they were all objects.

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (isString(value)) {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  if (isError(value)) {
    return prefix + value.message;
  }

  // We will never reach here
  throw new Error(`Invalid value type`);
};

interface Warning {
  text: string;
}

But if we create a function and say that our parameter is unknown, then it could be anything. Including primitive types, and that would throw an Error because we can only use the in operator in objects.

interface Warning {
  text: string;
}

const isWarning = (value: unknown): value is Warning => 'text' in value; // Compilation error

The solution is to make sure our parameter is a valid object before using the in operator. And we also need to make sure that it's not null.

interface Warning {
  text: string;
}

const isWarning = (value: unknown): value is Warning =>
  typeof value === 'object' && value !== null && 'text' in value;

Falsy Guard

For the falsy values guard, we first need to define a type with values that are considered falsy.

type Falsy = false | 0 | -0 | 0n | '' | null | undefined;

I'm not including NaN here because there is no NaN type in TypeScript.

type Falsy = false | 0 | -0 | 0n | '' | null | undefined | ~~NaN~~;

The type of NaN is number and not all numbers are falsy, so that's why we're not dealing with NaN.

typeof NaN;
//=> number

There is a proposal to add NaN as a type – and also integer, float and Infinity. I think that's nice, it would be helpful to have those types.

// Proposal
type number = integer | float | NaN | Infinity;

I'll leave a link for the proposal in the references.

Anyway, now that we have our Falsy type, we can create a falsy values guard.

Remember, a value is falsy if it's considered false when converted to a boolean. So, to check if our value is falsy, we can use abstract equality to see if it gets converted to false.

type Falsy = false | 0 | -0 | 0n | '' | null | undefined;

const isFalsy = (value: unknown): value is Falsy => value == false;

`formatErrorMessage()` with Custom Guards

That's it, we now have all the custom guards that we need for our formatErrorMessage() function.

// FUNCTION
const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (isFalsy(value)) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (isString(value)) {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if (isWarning(value)) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  if (isError(value)) {
    return prefix + value.message;
  }

  // We will never reach here
  throw new Error(`Invalid value type`);
};

// GUARDS
const isString = (value: unknown): value is string => typeof value === 'string';

const isError = (value: unknown): value is Error => value instanceof Error;

interface Warning {
  text: string;
}

const isWarning = (value: unknown): value is Warning =>
  typeof value === 'object' && value !== null && 'text' in value;

type Falsy = false | 0 | -0 | 0n | '' | null | undefined;

const isFalsy = (value: unknown): value is Falsy => value == false;

BONUS: Narrowing by Exclusion

Before we wrap this up, I want to show you something.

There is a limited list of falsy values, right?

1. `false`
2. `0` `-0` `0n` representations of zero
3. ```

` `""` `''` empty string
4. `null`
5. `undefined`
6. `NaN` not a number
`

But truthy values, on the other hand, are infinity. All values that are not falsy, are truthy.

So, how would make a type guard for truthy values?

Truthy Guard

The trick is to exclude the falsy types.

Instead of checking if our value is truthy, we check that it's not falsy.


ts
type Truthy<T> = Exclude<T, Falsy>;

const isTruthy = <T extends unknown>(value: T): value is Truthy<T> =>
  value == true;

// Test
const x = 'abc' as null | string | 0;
if (isTruthy(x)) {
  x.trim(); // `x: string`
}

I use this trick a lot, and we'll see it again in future articles.

Conclusion

References and other links are below.

If you haven't already, please like, subscribe, and follow us on social media. This helps us grow, which results in more free content for you. It's a win-win.

And if your company is looking for remote web developers, I and my team are currently available for new projects. You can contact us on lucaspaganini.com.

Have a great day, and I'll see you soon.

References

Fundamental Type Guards

Lucas Paganini — Thu, 09 Jun 2022 11:45:51 +0000

TypeScript Narrowing #2

See this and many other articles at lucaspaganini.com

Hey!

Welcome to the second article in our TypeScript narrowing series, where we go from fundamentals to advanced use cases.

Our Goal

In this article, I want to show you the fundamental type guards in practice. To do that, we will build a function that formats error messages before showing them to the end-user.

const formatErrorMessage =
  (value: ???): string => { ... }

Our function should be able to receive multiple different types and return a formatted error message.

const formatErrorMessage =
  (value: null | undefined | string | Error | Warning): string => { ... }

Are you ready? 🥁

The `typeof` Operator Guard

We'll start by supporting only two types: string and Error.

const formatErrorMessage =
  (value: string | Error): string => { ... }

To implement that function, we need to narrow the string | Error type to just a string and deal with it, then narrow it to just an Error and deal with it.

const formatErrorMessage = (value: string | Error): string => {
  const prefix = 'Error: ';

  // If it's a string, return the string with the prefix

  // If it's an Error, return the Error.message with the prefix
};

The first type guard that we'll explore is the typeof operator. This operator allows us to check if a given value is a:

"string"
"number"
"bigint"
"boolean"
"symbol"
"undefined"
"object"
"function"

Let's use it in our function.

const formatErrorMessage = (value: string | Error): string => {
  const prefix = 'Error: ';

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value; // <- value: string
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message; // <- value: Error
};

What's happening here is that the typeof value === 'string' statement is acting as a type guard for string. TypeScript knows that the only way for the code inside that if statement to run is if value is a string so it narrows the type down to string inside the if block.

Since we're returning something, value can't be a string after that if statement, so the only type left is Error.

The `in` Operator Guard

Sometimes we're not so lucky. For example, let's add a new type to our function, a custom interface called Warning.

const formatErrorMessage = (value: string | Error): string => {
  const prefix = 'Error: ';

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value; // <- value: string
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message; // <- value: Error
};

interface Warning {
  text: string;
}

Now our code is broken.

const formatErrorMessage = (value: string | Error | Warning): string => {
  const prefix = 'Error: ';

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value; // <- value: string
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message; // <- value: Error | Warning
};

interface Warning {
  text: string;
}

Before, our value variable could only be an Error instance after the if statement.

const formatErrorMessage = (value: string | Error): string => {
  const prefix = 'Error: ';

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value; // <- value: string
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message; // <- value: Error
};

interface Warning {
  text: string;
}

But now, it can be Error | Warning and the .message property doesn't exist in a Warning.

const formatErrorMessage = (value: string | Error | Warning): string => {
  const prefix = 'Error: ';

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value; // <- value: string
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message; // <- value: Error | Warning
};

interface Warning {
  text: string;
}

The typeof operator won't help us here because typeof value would be "object" for both cases.

const formatErrorMessage =
  (value: string | Error | Warning): string => {
    const prefix = 'Error: ';

    // If it's a string, return the string with the prefix
    if (typeof value === 'string') {
      return prefix + value // <- value: string
    }

    // If it's a Warning, return the Warning.text with the prefix
    if (???) {
      return prefix + value.text
    }

    // If it's an Error, return the Error.message with the prefix
    return prefix + value.message // <- value: Error | Warning
}

interface Warning {
  text: string
}

One of the idiomatic ways of handling that situation in JavaScript would be to check if value has the .text property. If it does, it's a Warning. We can do that with the in operator guard.

const formatErrorMessage = (value: string | Error | Warning): string => {
  const prefix = 'Error: ';

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value; // <- value: string
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text; // <- value: Warning
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message; // <- value: Error
};

interface Warning {
  text: string;
}

This operator returns true if the given object has the given property. In this case, if value has the .text property.

TypeScript knows that our if statement will only be true if value is a Warning because that's the only possible type for value that has a property called .text, so it narrows the type down to Warning inside the if block.

After the first, if statement, value can be Warning | Error. After the second if statement, it can only be Error.

Equality Narrowing

It's also very common to support optional arguments, which means, allowing value to be null or undefined.

const formatErrorMessage =
  (value: null | undefined | string | Error | Warning): string => {
    const prefix = 'Error: ';

    // If it's null or undefined, return "Unknown" with the prefix
    if (???) {
      return prefix + 'Unknown'
    }

    // If it's a string, return the string with the prefix
    if (typeof value === 'string') {
      return prefix + value // <- value: string
    }

    // If it's a Warning, return the Warning.text with the prefix
    if ('text' in value) {
      return prefix + value.text // <- value: Warning
    }

    // If it's an Error, return the Error.message with the prefix
    return prefix + value.message // <- value: Error
}

interface Warning {
  text: string
}

We could handle the undefined case with the typeof operator but that wouldn't work with null.

By the way, if you want to know why it wouldn't work for null and the differences between null and undefined. I have a very short and informative article explaining just that. I'll leave a link for it in the references.

What we could do that would work for null and undefined is to use equality operators, such as ===:

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's null or undefined, return "Unknown" with the prefix
  if (value === null || value === undefined) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message;
};

interface Warning {
  text: string;
}

Our if statement will only be true if value equals null or undefined, so TypeScript narrows our type to null | undefined.

That's called equality narrowing, and it also works with other comparison operators, such as:

Not equals !==
Loose equals ==
Loose not equals !=

Truthiness Narrowing

But here's the thing. Equality narrowing is not the idiomatic JavaScript way of checking for null | undefined. The idiomatic way of doing this is to check if the value is truthy.

I have a short article explaining what is truthy and falsy in JavaScript. I'll put the link in the references. It would be nice if you could go watch that real quick so that we have the definition of truthy and falsy fresh in our minds. Go ahead, I'm waiting.

Now that we all have the definition of truthy and falsy fresh in our minds, let me introduce you to truthiness narrowing.

Instead of using equality narrowing to check if value equals null or undefined, we can just see if it's falsy.

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message;
};

interface Warning {
  text: string;
}

We can do that by prefixing it with a logical NOT !. That will convert the value to a boolean and invert it. If it's falsy, it'll be converted to false and then inverted to true.

Control Flow Analysis

So far, we've been avoiding a guard to check if value is an instance of the Error class. I told you how we're managing to do that. We are treating all the possible types so that there's only the Error type left in the end.

That technique is very common in JavaScript, and it's also a form of narrowing. The correct term for what we've been doing is "Control Flow Analysis".

Control flow analysis is the analysis of our code based on its reachability.

TypeScript knows that we can't reach the first if statement unless value is truthy.

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  // if (typeof value === 'string') {
  // return prefix + value
  // }

  // If it's a Warning, return the Warning.text with the prefix
  // if ('text' in value) {
  // return prefix + value.text
  // }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message;
};

interface Warning {
  text: string;
}

We can't reach the second if statement unless value is a string.

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  // if ('text' in value) {
  // return prefix + value.text
  // }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message;
};

interface Warning {
  text: string;
}

We can't reach the third if it's not a Warning. So in the end, there's only one type left, it can only be an Error.

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  return prefix + value.message;
};

interface Warning {
  text: string;
}

Those types are being narrowed because TypeScript is using control flow analysis.

The `instanceof` Operator Guard

But we don't need to rely on control flow analysis to narrow our type to Error. We can do it with a very simple and idiomatic JavaScript operator. The instanceof operator.

const formatErrorMessage = (
  value: null | undefined | string | Error | Warning
): string => {
  const prefix = 'Error: ';

  // If it's falsy (null, undefined, empty string), return "Unknown" with the prefix
  if (!value) {
    return prefix + 'Unknown';
  }

  // If it's a string, return the string with the prefix
  if (typeof value === 'string') {
    return prefix + value;
  }

  // If it's a Warning, return the Warning.text with the prefix
  if ('text' in value) {
    return prefix + value.text;
  }

  // If it's an Error, return the Error.message with the prefix
  if (value instanceof Error) {
    return prefix + value.message;
  }

  // We will never reach here
  throw new Error(`Invalid value type`);
};

interface Warning {
  text: string;
}

Here we are checking if value is an instance of the Error class, so TypeScript narrows our type down to Error. There is no type left after that last if statement, we will never reach any code that comes after it.

Type `never` (15s)

If you're wondering what TypeScript considers to be the type of value after all of our if statements, the answer is never.

never is a special type that represents something impossible, something that should never happen.

Conclusion

Those were the fundamental type guards, they are super useful, but they will only take you so far. In the next articles, I'll show you how to create custom type guards. Subscribe if you don't want to miss it.

References are below.

And if your company is looking for remote web developers, you can contact me and my team on lucaspaganini.com.

As always, have a great day, and I'll see you soon!

References

What is a Type Guard. TypeScript

Lucas Paganini — Thu, 09 Jun 2022 11:45:26 +0000

TypeScript Narrowing #1

See this and many other articles at lucaspaganini.com

Gooooood morning/night/afternoon/whatever time it is right now.

And welcome. Welcome to the first article in our TypeScript narrowing series.

We have SO MUCH to cover! Going from the fundamentals, all the way up to advanced use cases.

In this series, we will cover:

What is a type guard
What is narrowing
What problems does it solve
Type guard operators
Equality narrowing
Truthiness narrowing
Control flow analysis
Type predicates
Custom type guards
Creating guards by exclusion
Discriminated unions
Assertion guards
Higher-order guards
Narrowing library

At this point, you probably don't even know what I'm talking about. And that's fine, you will get there. But first, subscribe to the newsletter to make sure you don't miss any future articles.

I'm Lucas Paganini, and on this website, we release web development tutorials. If that's something you're interested in, please subscribe to the newsletter.

Let's start with the concepts:

What is narrowing in TypeScript?

Narrowing is the process of refining a broader type to one that is more specific.

Broad → Specific
string → "abc"
number → 123
object → Date

For example, refining string to "abc", or number to 123, so on... You have a broader type, and you shrink it to something more specific.

Why do we need narrowing?

And why would do that? Well, to handle the cases individually.

If you have a variable that can be a string, a number, or a boolean. Then you probably want to handle those cases one by one.

If it's a string, do this. If it's a number, do that. And if it's a boolean, do this other thing. That is narrowing.

const doSomething = (value: string | number | boolean) => {
  // If it's a string, do this
  // If it's a number, do that
  // If it's a boolean, do this other thing
};

You have a broader type, which is the combination of string, number, and boolean. Then you narrow this broader type to just a string, then to a number, and then to a boolean.

To narrow the types, you can use type guards.

What is a type guard?

Type guards are narrowing techniques, they allow you to do narrowing.

"Lucas, let's be practical. How do they look like? Show me a type guard."

Ok, I'll show you. Just bear with me for a minute. I want to emphasize two things:

TypeScript is a superset of JavaScript. All JavaScript is valid TypeScript;
TypeScript wants to be as little intrusive as possible. Instead of forcing us into a new syntax, it will support idiomatic JavaScript ways of doing things. When possible!

See, narrowing is not a new issue, we've had to deal with it in JavaScript for years now. I bet that you were thinking of the typeof operator, while I was giving the last example.

The typeof operator allows us to narrow our types. So, it is a type guard.

// If it's a string, do this
if (typeof value === 'string') { ... }

There are many other type guards, and you can also create your own. We also have assertion guards, which is another way of doing narrowing.

Conclusion

For this first article, I'll leave it at that. References are below.

You now know the concepts of narrowing in TypeScript. But don't get used to it, in the next article, we'll get our hands dirty and practice those concepts.

I can't emphasize enough the amount of topics that we need to talk about. There is a lot to come.

And breaking that down to you in easy lessons, full of examples and animations, takes a lot of work. So I will play the role of the annoying content creator here, and kindly ask you to like and share this article. Share it with your colleagues. Share it in a Facebook group. Share it on Reddit. I don't know. But help us grow so that we keep making premium content like that for free.

We will soon release the second part of this article series, so subscribe to be notified when that happens.

If your company is looking for remote web developers, you can contact me and my team on lucaspaganini.com.

Have a great day, and I'll see you soon.

References

TypeScript docs on narrowing

Angular 13. What's new

Lucas Paganini — Thu, 09 Jun 2022 11:42:03 +0000

What's new in angular 13.

See this and many other articles at lucaspaganini.com

Angular 13 was recently released, let me tell you what I consider to be the most relevant changes.

Build Cache

You can now cache your builds, so if a module hasn't changed, Angular doesn't have to rebuild it. That alone will improve your build speed by around 68%.

{
  "cli": {
    "cache": {
      "enabled": true,
      "path": ".angular/cache",
      "environment": "all"
    }
  }
}

TestBed Destroy After Each

Tests are now faster because Angular does a better job of tearing down after each test. That introduced some race conditions in my codebase, so I had to turn that off. I'd say it needs a few weeks to become stable.

getTestBed().initTestEnvironment(
  BrowserDynamicTestingModule,
  platformBrowserDynamicTesting(),
  { teardown: { destroyAfterEach: false } }
);

Dropped Support for Internet Explorer 11

Finally, we're dropping support for Internet Explorer 11, which allows Angular to leverage modern browser features, such as CSS variables.

Dependency Updates

TypeScript 4.4 and RxJS 7.4 are now supported! I made a video on RxJS 7, the link is in the description.

Dynamically create components

If you create components dynamically, good news, you don't need the component factory anymore, just use ViewContainerRef.createComponent

const componentFactory =
  componentFactoryResolver.resolveComponentFactory(Component);

const componentRef = componentFactory.create(injector);

viewContainer.insert(componentRef.hostView);

const componentRef = viewContainer.createComponent(Component);

Conclusion

References are below. Subscribe if you're into web development, and have a great day.

DEV Community: Lucas Paganini

Mocking Concepts - What is Mocking

What is Mocking

Fake Interactions

Fake Data

When to Mock

Pros

Without mocking

Mocking

Cons

Best Practices of Mock Testing

1. Only mock types that you own

2. Don't mock return values of what's being tested

3. Don't mock everything

4. Use integration tests

5. Test failing cases

Don't Stop Here

References

What's new in Angular 14?

Introduction

Standalone components

Before Angular 14

A new possibility with Angular 14

Be aware!

Route Providers

ENVIRONMENT_INITIALIZER

Typed Forms

The inject() Function

Set Page title from the route

Angular CLI Autocomplete

Activating the CLI autocomplete

Optional injectors in Embedded Views

Don't Stop Here

References

Static, Unit, Integration, and End-to-End Tests Explained

Spoiler

Introduction - What is Software Testing

Static Tests

Linting

Type checking

Static code analysis

Other static tests

Unit Tests

Integration Tests

End-to-End Tests

Verdict

Don't Stop Here

References

Narrowing Library

Installing and Target Audience

Currently Available Modules

Core Module

Assertions Module

Predicates Module

Series Outro

Conclusion

Related Content

References

Asynchronous type guards

The Goal

The Workaround

Motivations for Asynchronous Type Guards

makeAsyncPredicateFunction

Conclusion

References

Higher Order Guards (Functions)

Higher Order Functions

Higher Order Guards

makeIsNot Implementation

makeIsNot Signature

Type Guard Function Type

Predicate Function Type

Unpack Predicate Function Type

Back to the Signature

Library

Conclusion

References

Assertion Functions or Assertion Guards

Assertion Functions vs Type Guards

Early Exits

The `inject()` Function

`makeAsyncPredicateFunction`

`makeIsNot` Implementation

`makeIsNot` Signature

The `unknown` Type

`Error` Guard

`Warning` Guard

`formatErrorMessage()` with Custom Guards

The `typeof` Operator Guard

The `in` Operator Guard

The `instanceof` Operator Guard

Type `never` (15s)