Using fp-ts for Functional Programming in TypeScript/

...

/

Defining Our Types

Defining Our Types

Learn about the project requirements and what types we need to define.

We'll cover the following...

Consider a scenario where our company has decided to add personalization to its products, so it will now need users to register. We’ve been tasked with quickly rolling out the first version of this user registration.

Let’s try working on this project in the proper way, by postponing our coding for a while to first think about our requirements. What does the information we receive look like? What does our user type look like? What functions will we need?

Setting up our project

We need a package.json file with the fp-ts package included as a dependency. We also require a tsconfig.json file with the target set to es6. Take a look at the sample files:

Press + to interact
{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es6",
    "outDir": "build"
  },
  "exclude": [
    "node_modules"
  ],
  "include": [
    "src/**/*"
  ]
}

In the src folder, we need another file called domain.ts, which contains all our types. We assume that we’ll receive a first name, last name, sex or gender, country, and age from the frontend or another application. We’ll call this incoming information UserRegistrationDto and add this to our domain.ts file as shown below.

Press + to interact
export type UserRegistrationDto = {
    firstName: string,
    lastName: string,
    age: number,
    sex: string,
    country: string,
};

Note: We often use the Event suffix for incoming data with the AWS Lambda computing platform because Lambdas are run in response to events. In that case, the above would be UserRegistrationEvent. DTO (Data Transfer Object) is another nice suffix, signifying that this is untrusted, outside information. We’re still on the edge of our domain/application, and transformations must happen before this DTO becomes a trusted object within our domain.

The core of our little user registration domain is a user. What will that type look like? We could just create something containing all the fields of UserRegistrationDto, name it User, and call it a day. But this isn’t ideal. Why would we stick with the very rough information and types we receive, when we can improve our types, thus making ...