🚀 WRITE BETTER TYPESCRIPT TOP 4— YOU SHOULD NOW

Have you ever thought to write more scalable TypeScript code?

Let’s suppose you’re building a system to handle employees for a company.

Every employee shares the same common data such as name, email, start data, department they belong or leaving date.

Althought, based on their profiles, they also have specific skills.

Those types may be similar to the following:

type EmployeeProfile = {
  id: string;
  firstName: string;
  lastName: string;
  email: string;
};

type EmploymentDetails = {
  department: string;
  hiredAt: Date;
  isActive: boolean;
  salary: number;
};

Now, based on the previous model.

We need to classify them according to their front and back profiles.

🔥 TOP 1 — GENERIC TYPES

type Employee<T> = EmployeeProfile & EmploymentDetails & T;

As you could noticed, I’ve used Employee<T> and T at the end.

This is known as TypeScript generic types.

In a short terms it allows us to reuse the same Employee structure such as EmployeeProfile and EmploymentDetails for each different profile.

Write these types to assign them to each employee with <> brackets.

type FrontendSkills = {
  programmingLanguage: "TypeScript" | "JavaScript";
  framework: "React" | "Angular" | "Vue";
};

type BackendSkills = {
  programmingLanguage: "Go" | "Java" | "Node.js";
  database: "PostgreSQL" | "MongoDB" | "MySQL";
};

type FrontendDeveloper = Employee<FrontendSkills>;
type BackendDeveloper = Employee<BackendSkills>;

🔥 TOP 2 — RECORD

Let’s suppose we want to check all the employee keys to make sure they match with their types and that none are missing.

That’s done using Record<Keys, Type>

type EmployeeKeys = keyof EmployeeProfile;

As a result to use keyof, we’ll get every EmployeeProfile keys, just like that:

type EmployeeKeys = "id" | "firstName" | "lastName" | "email";

Next, based on our previous EmployeeKeys above, we’ll use Record to check those keys.

First attempt

const EmployeeValidation: Record<EmployeeKeys, string> = {
  id: "132132112-8991",
  firstName: "Javi",
  lastName: "Mentor",
  email: "recordTypeScript@domain.com"
}

In this case, TypeScript won’t throw any error, as all fields match their type and already existed.

Second attempt

const EmployeeValidation: Record<EmployeeKeys, number[]> = {
  id: "132132112-8991",
  firstName: 1234,
  email: "recordTypeScript@domain.com"
}

What happened then?

Record will tell TypeScript that there are several errors. ❌

One of them is that EmployeeKeys expects strings instead than each property containing a list of numbers.

After that, lastName is mandatory and is now missing.

Finally, firstName is also wrong, as it expects a string instead than a number.

This is the code snippet generated on the second attempt.

{
  id: number[];
  firstName: number[];
  email: number[ ];
}

🔥 TOP 3 — OMIT / PICK

Let’s say you want to avoid sensitive data like employee’s salary that shouldn’t go to the frontend.

In this way, you would use Omit to remove it.

type PublicEmployee = Omit<BackendDeveloper, "salary">

Now, imagine you’re building an employee directory page for display a team list.

In my case, I wouldn’t need all the employees’ details.

Honestly, I would rather their ID numbers, name and the department to display their profile.

type EmployeeCard = Pick<Employee<FrontendSkills>, 
   "id" | "firstName" | "lastName" | "department">;

Finally, whether pick React to render this Employee data with a component, I would do the following code.

const EmployeeList = () => 
{
  return (
    <ul>
      {employees.map((employee) => {

        const { id, firstName, lastName, department } = employee;

        return (
          <li key={id}>
            <h3>
              {firstName} {lastName}
            </h3>
            <p>Department: {department}</p>
          </li>
        );
      })}
    </ul>
  );
};

However, as you could imagine this could be done with other frameworks that support TypeScript like Angular.

That’s no problem at all.

🔥 TOP 4 — EXTENDS

In this top 4, assume that our main system is growing so fast, and we need to create an isolated Employee interface instead.

Thus, every profile will follow the same properties but with different skills for each profile.

Pretty clean! 🧹

interface EmployeeBase extends EmployeeProfile, EmploymentDetails {}

interface FrontendDeveloper extends EmployeeBase {
  programmingLanguage: "TypeScript" | "JavaScript";
  framework: "React" | "Angular" | "Vue";
}

interface BackendDeveloper extends EmployeeBase {
  programmingLanguage: "Go" | "Java" | "Node.js";
  database: "PostgreSQL" | "MongoDB" | "MySQL";
}