DEV Community: Thomas Smith

TypeScript Getters and Setters

Thomas Smith — Thu, 28 Jan 2021 11:42:19 +0000

TypeScript supports using getters and setters in classes. This enables you to create properties on a class that can be retrieved or assigned dynamically. Let's take a look at a quick example:

class Person {
    public firstName: string;
    public lastName: string;

    constructor(firstName: string, lastName: string) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    get fullName(): string {
        return `${this.firstName} ${this.lastName}`
    }
}

const me = new Person("Tomy", "Smith");

console.log(me.fullName);

In the snippet above, we've created a class that has two properties: firstName and lastName. We've also created a getter function, get fullName(): string, that returns the first and last names as a single string (this is a very basic example that naively assumes everyone has a single first and last name: you should be mindful of the many, many different ways names are formatted and represented around the world).

You can see that, rather than calling fullName() on the instance of the class, we can access fullName it as if it were a property.

We can add a setter, using the set keyword:

class Person {
// ...
    set fullName(name: string) {
        const [first, last, ...rest] = name.split(' ');
        if (rest.length > 0) {
            throw new Error("Name can only have two parts: a first name and a last name.");
        }


        this.firstName = first;
        this.lastName = last;
    }
}

tom.fullName = "Thomas Smith";

Here, we split the passed in name (again, naively assuming that the passed in name is a first name, a space, and then a last name), and assign each part to the firstName and lastName properties. If the passed in name has more than two parts, we throw an error.

As you can see, this allows us to add additional functionality to assignment.

Use Cases

Why would you want to use getters and setters in your code? A few quick examples:

You want to set values with side effects, for example, updating the value of an instance might include computing the value, or updating other values alongside it.
Retrieval with side effects. For example, retrieving a value from a database or similar, or updating a cache with the new value.
You may wish to validate the kind of values that are passed to a setter. For example, only allowing numbers that are greater than a certain amount.
You may wish to abstract the internal representation of a value. For example, you could have a rectangle class that has a width property and a height property. You could create getter methods that allow you to return an area or a perimeter measurement using rect.area or rect.perimeter.
Backwards compatibility. You could create a getter for a property that used to exist on a class, that simply returns the new way of accessing the property (it could also log a deprecation warning or similar).
Fallback values. For example, return a property if it exists on the class, otherwise return a default value.

Gotchas

Accessors with only a get method are automatically inferred to be readonly. This means your code fail to compile if you attempt to assign a value to that property.

When interacting with the class, it is unclear if the property is a getter or setter (for example, you don't know that rect.area is a getter, you might assume that it is simply retrieving a property from the instance). Using a function is much better (i.e., rect.getArea()), as it is clear that work is being done to return the value.

Many people don't like accessor methods, for many, many reasons. For more on the pros and cons of the approach, check out Accessors are Evil.

Template Literal Types in TypeScript 4.1

Thomas Smith — Wed, 20 Jan 2021 23:59:23 +0000

A new feature in TypeScript 4.1 is the ability to create Template Literal Types. This feature allows you to use string interpolation to create types:

type World = "world";

type HelloWorld = `Hello ${World}`;

// type HelloWorld = "Hello world"

Looks interesting, right? This feature gets even more powerful when you combine it with union string literals:

type Vertical = "top" | "middle" | "bottom";
type Horizontal = "left" | "center" | "right";

type Position = `${Vertical}-${Horizontal}`;

declare function setPosition(pos: Position): void;

setPosition("top-right");
setPosition("bottom-left");

The union types are expanded to include every possible permutation! So we get access to top-center, bottom-right, top-left, and so on, and all the type safety that this brings. Hopefully you can see the potential here. For example, we can easily expand on this to add more options—I'm English, so we could add "centre" to the Horizontal type to enable a bit of localisation.

This example was lifted straight from the TypeScript release notes for Version 4.1, but I wanted to see what else I could come up with. Below is an example of using template literal types to create hex pairs, which we can then use in a makeColor function:

type HexNum = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9;
type HexLet = "a" | "b" | "c" | "d" | "e" | "f";
type HexChar = HexNum | HexLet;

type HexPair = `${HexChar}${HexChar}`

// Stub
type Color = {};

declare function makeColor(r: HexPair, g: HexPair, b: HexPair, a?: HexPair): Color;

makeColor("aa", "1a", "ff");
makeColor("ba", "da", "55", "e5");
makeColor("zz", "vv", "1j"); // error!

Here, we define all the possible hex characters, and then define a HexPair by using template literal types to join two HexChars together. We then use this type for each argument to the makeColor function, to enable type safety when passing in a hex pair.

Pretty neat!

Note: There's an upper limit on the size of a union type generated this way. For example, I tried joining my HexPair type three times to create a RGBColor type, but got a Expression produces a union type that is too complex to represent. error.

The code in this post is available in this TypeScript Playground.

Pipelines in TypeScript with Generics

Thomas Smith — Wed, 13 Jan 2021 21:04:42 +0000

I first encountered a "Pipeline" in code when working with Laravel a few jobs ago. Not long afterwards, I started learning Elixir in my spare time, which had a similar concept with its Pipe Operator. And of course, if you're familiar with Bash you'll know about piping output into other functions using the pipe |.

At the time, I really liked the expressive API that Laravel had created, allowing you to easily take an initial value, perform discrete operations on it and then spit it out or do something with it at the end.

I'd forgotten all about this feature, up until a few weeks ago when I wanted something similar in TypeScript. For example:

pipe(5)
  .throughFunctions(
    n => n + 2,
    n => n * 2
  )
  .return(); // 14

Of course, this example is just with a simple number and some predefined functions. But, imagine you were dynamically gathering a list of operations based on something:

const operations: ((arg0: number) => number)[] =
  gatherOperations();

pipe(5).throughFunctions(...operations).return()

Or maybe you're writing a small web framework, and wanted to pipe a request object through some middleware:

const IsAdminMiddleware = (request: Req) => {
    if (!request.body.isAdmin) {
        throw new AuthorizationError("Request is not from an Admin")
    }

    return request;
}

pipe(request)
  .throughFunctions(IsAdminMiddleware)
  .then((request) => {
    console.log(`Request ${request.id} processed successfully`)
  });

Hopefully you can see how this pattern might be useful to implement in your own code! Let's dig in and create a basic Pipeline.

Note: The Pipeline class we are creating will be limited to accepting and returning values of the same type. For example, once a pipeline is initialised with a number, only functions that accept and return a number can be used. Of course, there's nothing stopping you from expanding on this code to allow the type of the piped value to change as it progresses through the pipeline, but it's out of scope for this tutorial.

Creating the Pipeline Class

Under the hood, the pipe method we used above just creates a new instance of a Pipeline class. Let's create this. We're using generics here to enable some type guarantees when passing functions to our pipeline.

class Pipeline<T> {
  constructor(private param: T) {}
}

new Pipeline(5)

new Pipeline<string>("Hello")

And then let's create the shorthand pipe function:

function pipe<T>(value: T): Pipeline<T> {
  return new Pipeline<T>(value);
}

Creating the `throughFunctions` method

We want to be able to pipe this data through a list of functions, but we also want type safety around these functions, so that we can catch more errors when we are developing.

For example, imagine if we didn't have type safety:

pipe("hello").throughFunctions(
  // What happens when you multiply "hello" by 2?
  // You get a NaN, that's what.
  n => n * 2
).return();

So, we want our throughFunctions method to use the type that we defined when creating our Pipeline class:

class Pipeline<T> {
    // ...

    throughFunctions(...funcs: ((param: T) => T)[]): Pipeline<T> {
        funcs.forEach(func => {
            this.param = func(this.param);
        });

        return this;
    }
}

Unpacking this, you'll see this is a variadic method, meaning we can pass in one or more of the value for funcs. The type of the funcs parameter is (param: T) => T)[] — this means an array ([]) of functions that have one parameter of type T that return the type T. For example, our n => n + 2 function in the introduction.

You should also note that the function returns the type Pipeline<T> — this is the type of the current class! This allows us to chain together multiple methods, which you'll often find is called a fluent interface or method chaining.

Inside the function is pretty straight forward. We're looping through each of the functions that have been passed in and are executing them, passing in the current value and reassigning it to the result.

At the end of the throughFunctions method, we're returning this to satisfy the Pipeline<T> return value.

Creating a `return` method

Phew! Almost done. Our Pipeline can now pass our data through as many functions as it wishes. Now all we need is a way to unpack the value contained inside it.

Let's create a return method on our class. (I wasn't sure if creating a method called "return" was valid, but it seems to work without issue!)

class Pipeline<T> {
    // ...

    return(): T {
        return this.param;
    }
}

That's it! We're saying that the return type will be T, which will match the type of the initial value we passed in. Then, we just return the private property param, which we defined back in the Pipeline class's constructor.

Conclusion

That should just about do it!

As I mentioned earlier, this is a fairly basic implementation of the Pipeline pattern, but has suited my needs so far. If you're tempted to push this further, why not try:

Allowing objects to be passed in via a throughObjects method. These objects would need to implement an interface (maybe have a handle method: throughObjects(...objs: { handle(arg0: T): T }[]): Pipeline<T>) to ensure that they could be called successfully.
Allowing the type to be mutated as the Pipeline progressed. This would complicate the Pipeline a little, but would make it way more powerful. For example, starting with a number, and allowing further steps to turn this into an array of numbers, then an object that contains that array.

Photo by Quinten de Graaf on Unsplash