Toxic optionals - TypeScript
Tags: typescript, cleancode, javascript, beginners
Published: 2021-09-28 21:03:44

[In my previous blog post](https://dev.to/latobibor/toxic-flexibility-a-case-for-typescript-6ff) I was talking about the inherent **Toxic flexibility** of the `JavaScript` language itself.

I made a case for cutting down the number of options a piece of code can have so our tool chain including your IDE of choice can help you serving with just the right thing you need at the right moment, or help you "remember" every place a given object was used without having to guess it by use a "Find in all files" type dialog.

However **toxic flexibility** can sprout up in `TypeScript` as well.

Let's start with a real life product example!

## Building a survey
In our company we have to deal with surveys aka questionnaires. Overly simplified each `survey` will have a number of `question`s of different types.

Let's say our product manager says: _"I want people to have the ability to add an **integer** or a **string** question."_

For example: 
- How many batteries were present? => `integer question`
- How would you describe your experience? => `string question`

Let's write the types down (I omit most of the details like IDs to keep it clean):

```typescript
type Question = {
  answerType: 'string' | 'integer';
  label: string;
}
```

The next day the product manager comes in and says: _"I want these types to have constraints: a `string` question might have `minimum` and `maximum lengths`, while `integer` questions might have `minimum` and `maximum values`."_

OK, we scratch our heads and then decide to go "smart" and say: _"You know what? I will have just a `min` and `max` property. The property `min` will mean if it is `string` a `minimum length` and if it is `integer` a `minimum value`."_

```typescript
type Question = {
  answerType: 'string' | 'integer';
  label: string;
  min: number;
  max: number;
}
```

(Note: at this point we started to stray away from `true domain objects` to make our _initial_ implementation simpler. I will come back to this later.)

The next day the product manager comes in again: _"All was well and good, but now I want a `boolean` question (a yes-no one), which does not have a `min-max` type of constraint. Also I want `min-max` values to be optional. Also people want to make photos and want to have a constraint over the maximum number of photos they can make but I do not wish to set a minimum."_

So we go and update our type:
```typescript
type Question = {
  answerType: 'string' | 'integer' | 'yes-no' | 'images';
  label: string;
  min?: number;
  max?: number;
  maxNumberOfPhotos?: number;
}
```

Finally the product manager comes to tell: _"Oh no, I completely forgot! We want people to have a question type where they select from a list of options with a radio button. I will call it `single choice`."_

Now things start to sour:
```typescript
type Question = {
  answerType: 'string' | 'integer' | 'yes-no' 
            | 'image' | 'single-choice';
  label: string;
  min?: number;
  max?: number;
  maxNumberOfPhotos?: number;
  choices?: string[];
}
```

Looks like we can handle all these types with one excellent `type`! Or is there a drawback...? 🤔

## Cartesian products and the poison of optional properties
Let's see what kind of objects we can make from this `Question` type:

```typescript
// no surprises
const validImage: Question = {
  answerType: 'image',
  maxNumberOfPhotos: 3,
};

const validInteger: Question = {
  answerType: 'integer',
  min: 1,
  max: 10,
};

// but also this will compile...
const invalidYesNo: Question = {
  answerType: 'yes-no',
  maxNumberOfPhotos: 13,
  choices: ['lol', 'wat'],
}
```

Whenever you use optional you create the Cartesian product of all possible missing and added properties! We have 4 optional properties now we will have 2<sup>4</sup> options: 16 possible types of which only 4 of them are `valid domain objects`!

### Look at how it all ends... up ⚠️
A several years in my coding career I got really aware that to write good code I should not just see my module (be it a class or a function or a component) on its own, I constantly need to check how it is used: is it easy or is it cumbersome to interact with the object I have just defined.

The type I created above will be extremely cumbersome to use:
```typescript
// overly simplified logic just to show the problem
// This is a simple React example, don't worry if you 
// are not familiar with it
function ShowQuestion(question: Question) {
  if (question.type === 'yes-no' 
   && (question.max 
      || question.min 
      || question.maxNumberOfPhotos 
      || question.choices)) {
    throw new Error('Uh-oh, invalid yes-no question!');
  }

  if (question.type === 'single-choice' 
   && (question.max 
      || question.min 
      || question.maxNumberOfPhotos)
   && !question.choices) {
    throw new Error('Uh-oh, invalid single-choice question!');
  }
  
   // and so on and so on - finally we can show it

  return <div>
    {question.max && question.type === 'integer' && 
  <Constraint label="Maximum value" value={question.max} />}
    {question.maxNumberOfPhotos && question.type === 'image' &&
   <Constraint label="Maximum no of photos" 
 value={question.maxNumberOfPhotos} />}
    ...
  </div>;
}

```

### Optional properties and distinct domain types are not going well together
**Optional properties** are _totally fine_ when you work with, say, customization options like styling: you only set what you wish to change from a sensible default.

> However in this case we tried to describe several distinct domain types with just one type!

Just imagine if you only had one HTML tag and you would need to set tons of flags to achieve the same behaviors `div`, `p` and other tags would do:

```html
<!-- how a p tag would look like -->
<the-only-tag
  type="paragraph"
  flow-content="yes"
  block="yes"
  types-that-cannot-be-children="ul, ol, li"
>
 This would be a nightmare to work with as well!
</the-only-tag>
```

Drill this into your forehead:

> Every `optional property` you set up will warrant at least an `if` somewhere else.

If you need to describe **multiple domain objects** with _only one type_ you are most likely will need to use tons of `if`s and duck typings...

Therefore in this particular use case `optional` became toxic.

## `Union type` to the rescue!
I promised to come back to the domain objects. In everyone's mind we only have 5 types. Let's make then only five (plus a base)!

```typescript
type QuestionBase = {
  answerType: 'string' | 'integer' | 'yes-no' 
            | 'image' | 'single-choice';
  label: string;
}

// I am not going to define all of them, they are simple
type IntegerQuestion = QuestionBase & {
  // pay attention to this: answerType is now narrowed down
  // to only 'integer'!
  answerType: 'integer';
  minValue?: number;
  maxValue?: number;
}

type ImageQuestion = QuestionBase & {
  answerType: 'image';
  // we can make now things mandatory as well!
  // so if product says we must not handle
  // infinite number of photos
  maxNumberOfPhotos: number;
}

// ...

type Question = IntegerQuestion | ImageQuestion; 
// | YesNoQuestion | ...
```

How do we use them? We are going to use [`narrowing`](https://www.typescriptlang.org/docs/handbook/2/narrowing.html) (see link for more details).

### A case for some `switch-case`
One of my favourite things to do when you have to deal with a stream of polymorphic objects is to use `switch-case`:

```typescript
function renderAllQuestions(questions: Question[]) {
  questions.forEach(question => renderOneQuestion(question));
}

function renderOneQuestion(question: Question) {
  // question.type is valid on all question types
  // so this will work
  switch (question.type) {
    case 'integer':
      renderIntegerQuestion(question);
      return;
    case 'string':
      renderStringQuestion(question);
      return;
    //...
  }
}

// Check the type! We are now 100% sure
// it is the right one.
function renderIntegerQuestion(question: IntegerQuestion) {
  // your IDE will bring `maxValue` up after you typed 'ma'
  console.log(question.maxValue);

  return <div>
    {question.maxValue && 
      <Constraint label="Maximum value" value={question.maxValue} />
  </div>
}

// ...
```

_Disclaimer_: I know there are nicer React patterns than having a render function for everything. Here I just wanted to make a kind of framework-agnostic example.

What happened above is that we were able to _funnel_ a set of types to concrete types without having to use the dangerous `as` operator or to feel out the type at hand with duck-typing.

## Summary
To sum it all up:
* `optional properties` result in conditions that check them leading to **Cartesian product explosion**
* we cut down the number of **invalid possibilities** to only **5 valid `domain objects`**
* these `domain objects` also **match the terminology** product management and clients have
* since we **encapsulated** what is common in `QuestionBase` now we are free to add question specific extras and quirks
* **instead of having a god-component** question handler that handles rendering of a question with an insane set of conditions (and growing!) we now boxed away the differences neatly in **separate, aptly-typed components**
* we can also handle an **array of different values** and without any type casting with (e.g. `question as IntegerQuestion`) we created a type-safe system

Questions? Did I make errors?
Let me know in the comments.