DEV Community: Hans Ott (journy.io)

How to check if string is member of union type

Hans Ott (journy.io) — Mon, 12 Jul 2021 14:02:31 +0000

There's some ongoing debate whether enum in TypeScript should be used: The Dangers of TypeScript Enums

A TypeScript enum is compiled to an object at runtime:

enum Suits {
  Hearts = "hearts",
  Diamonds = "diamonds",
  Spages = "spades",
  Clubs = "clubs"
}

var Suits;
(function (Suits) {
    Suits["Hearts"] = "hearts";
    Suits["Diamonds"] = "diamonds";
    Suits["Spages"] = "spades";
    Suits["Clubs"] = "clubs";
})(Suits || (Suits = {}));

One benefit of this approach is being able to check at runtime whether a string is a member of the enum:

function isSuit(value: string): value is Suits {
  return Object.values(Suits).includes(value)
}

The alternative for enum is using a union type:

type Suit = "hearts" | "diamonds" | "spades" | "clubs"

Type information doesn't exist at runtime, how can we check at runtime if a string is a member of the union type?

function isSuit(value: string): value is Suit {
  return ["hearts", "diamonds", "spades", "clubs"].includes(value as Suit)
}

This works but there is an issue with this approach... When you add or remove members, we need to update the array. This is prone to errors because we might forget to update the array or the type. How can we do this automatically?

const ALL_SUITS = ['hearts', 'diamonds', 'spades', 'clubs'] as const;
type SuitTuple = typeof ALL_SUITS;
type Suit = SuitTuple[number];

function isSuit(value: string): value is Suit {
  return ALL_SUITS.includes(value as Suit)
}

We define the possible options using an array with a const assertion. A const assertion tells the compiler to infer the narrowest or most specific type it can for an expression. If you leave it off, the compiler will use its default type inference behavior, which will possibly result in a wider or more general type.

This gets compiled to

const ALL_SUITS = ['hearts', 'diamonds', 'spades', 'clubs'];

function isSuit(suit) {
    return ALL_SUITS.includes(suit);
}

Which is a lot nicer than using an enum! 🤩

Let me know if this blogpost was useful! 😊

Simple way to serialize objects to JSON in TypeScript

Hans Ott (journy.io) — Thu, 24 Jun 2021 14:21:09 +0000

When we’re building an application we often need to serialize objects to JSON for storing them in a key value store (e.g. Redis) or publishing them on a queue.

While there are libraries available like class-transformer or io-ts, there's an easier way to serialize/unserialize objects to JSON.

class-transformer depends on the reflect-metadata package. Read this blogpost to know why you should be careful with depending on this package.

io-ts requires knowledge of some functional programming concepts. While I'm a big fan of functional programming, it's not for everyone. (The library is very well designed though)

In both cases we also need to depend on an extra package.

We want to keep our dependencies as small as possible.

What none of these packages offer is a way to deal with backwards compatibility (e.g. when you've added or renamed a property of an object).

I also want something simple.

Let's say we want to serialize a user with an email value object to JSON:

class Email {
  constructor(private readonly email: string) {
    if (!this.email.includes("@")) {
      throw new Error(`Not an email address: ${this.email}`);
    }
  }

  asString() {
    return this.email;
  }
}

class User {
  constructor(
    private readonly id: string,
    private readonly email: Email
  ) {
    if (!this.id) {
      throw new Error("User ID cannot be empty!");
    }
  }

  private toObject() {
    return {
      id: this.id,
      email: this.email.asString(),
    }
  }

  serialize() {
    return JSON.stringify(this.toObject());
  }

  static fromSerialized(serialized: string) {
    const user: ReturnType<User["toObject"]> = JSON.parse(serialized);

    return new User(
      user.id,
      new Email(user.email)
    );
  }
}

const user = new User("id", new Email("john.doe@acme.com"));
const json = user.serialize();

const json = await redis.get(key);
const user = User.fromSerialized(json);

We add a private toObject() method that returns a plain object for the User (since JSON is not aware of classes).
We add a serialize() method that returns the plain object as a JSON string.
We add a static unserialize(serialized: string) method to recreate the User instance. JSON.parse has any as return type, which results in no type checking or autocompletion. We can grab the return type of the toObject() method with ReturnType<User["toObject"]> to regain type checking/autocompletion.
Always guard against invalid state in your entities. This makes sure that a User always has an ID and a valid email address.
Look ma, no packages needed!

Let me know if this blogpost was useful! 😊

The most common problem in React code

Hans Ott (journy.io) — Tue, 22 Jun 2021 18:38:43 +0000

I started playing with React about 5 years ago. The most common problem I've seen in React code is duplicate state.

Duplicate state always leads to problems.

So what do I mean with duplicate state?

Let's say we have a component that displays blogposts:

function Blogposts({ blogposts }) {
  return <ul>{blogposts.map(blogpost => ...)}</ul>
}

If we want to add a search to this list of blogposts:

function Blogposts({ blogposts }) {
  const [filtered, setFiltered] = useState(blogposts)
  const [search, setSearch] = useState("")

  return (
    <div>
      <input
        type="text"
        onChange={e => {
          setSearch(e.target.value)
          setFiltered(
            blogposts.filter(
              blogpost => e.target.value === "" || blogpost.title.includes(e.target.value))
            )
          )
        }}
        value={search}
        placeholder="Search"
      />
      <ul>{filtered.map(blogpost => ...)}</ul>
    </div>
  )
}

Note: We want to show all blogposts if the search is empty (e.target.value === "")

This will work but there are some flaws with this approach:

If blogposts changes, we'll need to make sure that the filtered list is updated
If we want to persist the search parameter across pages (e.g. using a query parameter) we'll need to make sure the filtered list is initialised correctly
The component is hard to reason about

We'll have to make sure filtered is always up-to-date.

This becomes a lot harder with bigger components.

How can we fix this?

In this case we can calculate the filtered list if we have blogposts and search:

function Blogposts({ blogposts }) {
  const [search, setSearch] = useState("")

  return (
    <div>
      <input
        type="text"
        onChange={e => setSearch(e.target.value)}
        value={search}
        placeholder="Search"
      />
      <ul>
       {blogposts
         .filter(
           blogpost => search === "" || blogpost.title.includes(search)
         )
         .map(blogpost => ...)
       }
      </ul>
    </div>
  )
}

We calculate the filtered list as part of the render cycle of the component.

Whenever the state changes, the component will re-render.

This means that we no longer have to keep filtered up-to-date:

We free our minds from having to think about filtered
The filtered list will always be correct
The component is easier to reason about

So here's my personal rule:

Always derive from the state if possible.

What about performance?

In most cases it's negligible because JavaScript is fast (unless you're computing heavy stuff).

You can use useMemo if you need too.

Let me know if this blogpost was helpful! 😊