Forbidden Typescript - idmontie's Portfolio

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    blockquote: "blockquote",
    code: "code",
    em: "em",
    h2: "h2",
    p: "p",
    pre: "pre",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsxs(_components.p, {
      children: ["In “Javascript: The Definitive Guide” there is an example that uses ", _jsx(_components.code, {
        children: "Object.inherit"
      }), " to inherit the prototype change. JavaScript defines a method ", _jsx(_components.code, {
        children: "Object.create"
      }), " that creates a new object using the given argument as the prototype of that object. Translating the examples from The Definitive Guide to Typescript, it looks like:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function inherit<T extends object>(obj: T): T {\n    return Object.create(obj);\n}\n\nclass MyObject {\n    public a: number;\n\n    constructor(a: number) {\n        this.a = a;\n    }\n}\nconst myObject = new MyObject(123);\nconst myClone = inherit(myObject);\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABDMALApgJxlAPAFUXQA8p0wATAZ0TgCMArdaAPgAp6GAuRfASh6EA3gChE4xJnRQQmJAHlGzKADoIUgIZkOjPgG4RAXxEiIAGw1UaAWQCeiptESiJiAA4g6ZmBEQaeYCAAtnRYBmISEAhUUJgg0HCYbP6IgSFYfM4RruJQqDBUKhqIALx+Bq7GxlFgMYhB9kpOZWDoAO6Idg7KbACMAEwAzPqm0VD1tgDCZgjopchoWDhsDd3QI6O1cGboKjMA5iuNjlD6iAD0585+PAODiNXR27sHR9OzZ5fOj1s7e3CHBrvVoLGIaSDoODATrHZSfK6xEDoERAA",
        children: "Playground Link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["However, we lied. Notice that in the above code, the ", _jsx(_components.code, {
        children: "myClone"
      }), " object was created without ", _jsx(_components.code, {
        children: "a"
      }), " being initialized."]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "console.log(myObject); // { a: 123 }\nconsole.log(myClone); // {}\nconsole.log(myClone instanceof MyObject); // true\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["This creates what is known as a ", _jsx(_components.em, {
        children: "type-hole"
      }), ": the Typescript compiler will not report any bugs when we try to use ", _jsx(_components.code, {
        children: "myClone.a"
      }), ".  That’s because we used ", _jsx(_components.code, {
        children: "Object.create"
      }), " which returns the ", _jsx(_components.code, {
        children: "any"
      }), " type. In the above example, if we tried to use ", _jsx(_components.code, {
        children: "myClone.a"
      }), " in a case where we expected a ", _jsx(_components.code, {
        children: "number"
      }), ", but got ", _jsx(_components.code, {
        children: "undefined"
      }), ", we can end up with runtime bugs that should have been caught by the compiler."]
    }), "\n", _jsx(_components.p, {
      children: "We can make the typings a little more clear by doing the following:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function inherit<T extends object>(obj: T): Partial<T> {\n    return Object.create(obj);\n}\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Now Typescript will report that the value of ", _jsx(_components.code, {
        children: "myClone.a"
      }), " might be undefined."]
    }), "\n", _jsx(_components.p, {
      children: "Let’s improve this a bit more and create an object that inherits and freezes the data in the given object:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function inheritAndFreeze<T extends object>(obj: T, values: Partial<T>): Readonly<Partial<T>> {\n    const properties: PropertyDescriptorMap = {};\n\n    Object.keys(obj).forEach((unsafeKey) => {\n        const key = unsafeKey as keyof T;\n        properties[key] = {\n            value: values[key] ?? undefined,\n            writable: false,\n            configurable: false,\n        };\n    })\n\n    return Object.create(obj, properties);\n}\n\nclass MyObject {\n    public a: number;\n\n    constructor(a: number) {\n        this.a = a;\n    }\n}\n\nconst myObject = new MyObject(123);\nconst myClone = inheritAndFreeze(myObject, { a: 123 });\n\nconsole.log(myClone); // { a: 123 }\nmyClone.a = 999; // Would throw \"Cannot assign to read only property 'a' of object '#<MyObject>' \"\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?ssl=29&ssc=102&pln=1&pc=1#code/GYVwdgxgLglg9mABDMALApgJxlAgmAEwDFN10AvdAHgBVF0APKdQgZ0TgCMArdaAPgAUXbgC5ENADSIAbgEMANiHStxABTmZYi2vwCU4gEro5BBAoCeVDVpg6a-fogDeAKEQfEEBKyiIADphw-liwKupBIVoWACIqENj+UHCYALJy-ogAvC4AvgDcru6eAPI8fFAAdADW6Baswjx6lcApAKJyEKiCguCscsDoANJ1etlObp5TXj5+tRbZiH0Dw3WIcuzzcMAShdOegcGhMCoA2vMAuouT+9PySuji98qs53VXAPwfS4TowCjoAiSYq3TwAd2wUDknAUj0QwEUrHQwIAkGj0d4wP8AOYgTDQ2HiBEKJHA0EFEGIXJ6IpTUhQPFIMq8aCVBImZiNbjSQ5RMKsPSFXJFCAKDbsVIWZkVFyU-wgGEwCDrcRgEAAW04WEKlMxvkwIGgKUEclVGq1mDGN32UFQMFYlTkizke08wuFrj1fnVUvK0EWYHQYMQkul0EEAEYAEwAZkFntmiB9AGEFAh0IsUBhIfhiKQKOhBD6w1BpM4VYhozGqfGE2BWHBYZU09iixZU+nBYgAPTdkO+ll+ZzCvWN9DNuCtlNpwOOru9yux1wL6fpx2LACcW-yPb7AHU4CAFARELagsGAETJuRgMBwPzimDYpDJRCkUwcMCWAKRUILADkcj-hwOwiDK-4AMRUKGfpQPwwEXkAA",
        children: "Playground Link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["If we didn’t mark the return value as ", _jsx(_components.code, {
        children: "Readonly<Partial<T>>"
      }), ", and instead just had ", _jsx(_components.code, {
        children: "Partial<T>"
      }), " we would once again have a type-hole and ", _jsx(_components.code, {
        children: "myClone.a = 999;"
      }), " would be allowed by Typescript, but would throw an exception at runtime because property a is read only as a runtime constraint."]
    }), "\n", _jsx(_components.h2, {
      children: "The Takeaway"
    }), "\n", _jsxs(_components.p, {
      children: ["Let’s step back and really look at what ", _jsx(_components.code, {
        children: "inherit"
      }), " was doing. All it gave us was a template object, and if you read on ", _jsx(_components.a, {
        href: "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain",
        children: "MDN about Inheritance and prototype chaining"
      }), ":"]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsxs(_components.p, {
        children: ["You may also see some legacy code using ", _jsx(_components.code, {
          children: "[Object.create()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create)"
        }), " to build the inheritance chain. However, because this reassigns the ", _jsx(_components.code, {
          children: "prototype"
        }), " property and removes the ", _jsx(_components.code, {
          children: "[constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/constructor)"
        }), " property, it can be more error-prone, while performance gains may not be apparent if the constructors haven't created any instances yet."]
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["The key here is to be wary of using utility functions built into the language that return the ", _jsx(_components.code, {
        children: "any"
      }), " type. Be careful what the Typescript constraints are and make sure you don’t have any type-holes when you are using these generic functions."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>In “Javascript: The Definitive Guide” there is an example that uses <code>Object.inherit</code> to inherit the prototype change. JavaScript defines a method <code>Object.create</code> that creates a new object using the given argument as the prototype of that object. Translating the examples from The Definitive Guide to Typescript, it looks like:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">function inherit&lt;T extends object&gt;(obj: T): T {
    return Object.create(obj);
}

class MyObject {
    public a: number;

    constructor(a: number) {
        this.a = a;
    }
}
const myObject = new MyObject(123);
const myClone = inherit(myObject);
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABDMALApgJxlAPAFUXQA8p0wATAZ0TgCMArdaAPgAp6GAuRfASh6EA3gChE4xJnRQQmJAHlGzKADoIUgIZkOjPgG4RAXxEiIAGw1UaAWQCeiptESiJiAA4g6ZmBEQaeYCAAtnRYBmISEAhUUJgg0HCYbP6IgSFYfM4RruJQqDBUKhqIALx+Bq7GxlFgMYhB9kpOZWDoAO6Idg7KbACMAEwAzPqm0VD1tgDCZgjopchoWDhsDd3QI6O1cGboKjMA5iuNjlD6iAD0585+PAODiNXR27sHR9OzZ5fOj1s7e3CHBrvVoLGIaSDoODATrHZSfK6xEDoERAA">Playground Link</a></p>
<p>However, we lied. Notice that in the above code, the <code>myClone</code> object was created without <code>a</code> being initialized.</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">console.log(myObject); // { a: 123 }
console.log(myClone); // {}
console.log(myClone instanceof MyObject); // true
</code></pre></div>
<p>This creates what is known as a <em>type-hole</em>: the Typescript compiler will not report any bugs when we try to use <code>myClone.a</code>.  That’s because we used <code>Object.create</code> which returns the <code>any</code> type. In the above example, if we tried to use <code>myClone.a</code> in a case where we expected a <code>number</code>, but got <code>undefined</code>, we can end up with runtime bugs that should have been caught by the compiler.</p>
<p>We can make the typings a little more clear by doing the following:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">function inherit&lt;T extends object&gt;(obj: T): Partial&lt;T&gt; {
    return Object.create(obj);
}
</code></pre></div>
<p>Now Typescript will report that the value of <code>myClone.a</code> might be undefined.</p>
<p>Let’s improve this a bit more and create an object that inherits and freezes the data in the given object:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">function inheritAndFreeze&lt;T extends object&gt;(obj: T, values: Partial&lt;T&gt;): Readonly&lt;Partial&lt;T&gt;&gt; {
    const properties: PropertyDescriptorMap = {};

    Object.keys(obj).forEach((unsafeKey) =&gt; {
        const key = unsafeKey as keyof T;
        properties[key] = {
            value: values[key] ?? undefined,
            writable: false,
            configurable: false,
        };
    })

    return Object.create(obj, properties);
}

class MyObject {
    public a: number;

    constructor(a: number) {
        this.a = a;
    }
}

const myObject = new MyObject(123);
const myClone = inheritAndFreeze(myObject, { a: 123 });

console.log(myClone); // { a: 123 }
myClone.a = 999; // Would throw &quot;Cannot assign to read only property &#x27;a&#x27; of object &#x27;#&lt;MyObject&gt;&#x27; &quot;
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?ssl=29&amp;ssc=102&amp;pln=1&amp;pc=1#code/GYVwdgxgLglg9mABDMALApgJxlAgmAEwDFN10AvdAHgBVF0APKdQgZ0TgCMArdaAPgAUXbgC5ENADSIAbgEMANiHStxABTmZYi2vwCU4gEro5BBAoCeVDVpg6a-fogDeAKEQfEEBKyiIADphw-liwKupBIVoWACIqENj+UHCYALJy-ogAvC4AvgDcru6eAPI8fFAAdADW6Baswjx6lcApAKJyEKiCguCscsDoANJ1etlObp5TXj5+tRbZiH0Dw3WIcuzzcMAShdOegcGhMCoA2vMAuouT+9PySuji98qs53VXAPwfS4TowCjoAiSYq3TwAd2wUDknAUj0QwEUrHQwIAkGj0d4wP8AOYgTDQ2HiBEKJHA0EFEGIXJ6IpTUhQPFIMq8aCVBImZiNbjSQ5RMKsPSFXJFCAKDbsVIWZkVFyU-wgGEwCDrcRgEAAW04WEKlMxvkwIGgKUEclVGq1mDGN32UFQMFYlTkizke08wuFrj1fnVUvK0EWYHQYMQkul0EEAEYAEwAZkFntmiB9AGEFAh0IsUBhIfhiKQKOhBD6w1BpM4VYhozGqfGE2BWHBYZU09iixZU+nBYgAPTdkO+ll+ZzCvWN9DNuCtlNpwOOru9yux1wL6fpx2LACcW-yPb7AHU4CAFARELagsGAETJuRgMBwPzimDYpDJRCkUwcMCWAKRUILADkcj-hwOwiDK-4AMRUKGfpQPwwEXkAA">Playground Link</a></p>
<p>If we didn’t mark the return value as <code>Readonly&lt;Partial&lt;T&gt;&gt;</code>, and instead just had <code>Partial&lt;T&gt;</code> we would once again have a type-hole and <code>myClone.a = 999;</code> would be allowed by Typescript, but would throw an exception at runtime because property a is read only as a runtime constraint.</p>
<h2>The Takeaway</h2>
<p>Let’s step back and really look at what <code>inherit</code> was doing. All it gave us was a template object, and if you read on <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain">MDN about Inheritance and prototype chaining</a>:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>You may also see some legacy code using <code>[Object.create()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create)</code> to build the inheritance chain. However, because this reassigns the <code>prototype</code> property and removes the <code>[constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/constructor)</code> property, it can be more error-prone, while performance gains may not be apparent if the constructors haven&#x27;t created any instances yet.</p>
</blockquote>
<p>The key here is to be wary of using utility functions built into the language that return the <code>any</code> type. Be careful what the Typescript constraints are and make sure you don’t have any type-holes when you are using these generic functions.</p>


In “Javascript: The Definitive Guide” there is an example that uses `Object.inherit` to inherit the prototype change. JavaScript defines a method `Object.create` that creates a new object using the given argument as the prototype of that object. Translating the examples from The Definitive Guide to Typescript, it looks like:

```tsx
function inherit<T extends object>(obj: T): T {
    return Object.create(obj);
}

class MyObject {
    public a: number;

    constructor(a: number) {
        this.a = a;
    }
}
const myObject = new MyObject(123);
const myClone = inherit(myObject);
```

[Playground Link](https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABDMALApgJxlAPAFUXQA8p0wATAZ0TgCMArdaAPgAp6GAuRfASh6EA3gChE4xJnRQQmJAHlGzKADoIUgIZkOjPgG4RAXxEiIAGw1UaAWQCeiptESiJiAA4g6ZmBEQaeYCAAtnRYBmISEAhUUJgg0HCYbP6IgSFYfM4RruJQqDBUKhqIALx+Bq7GxlFgMYhB9kpOZWDoAO6Idg7KbACMAEwAzPqm0VD1tgDCZgjopchoWDhsDd3QI6O1cGboKjMA5iuNjlD6iAD0585+PAODiNXR27sHR9OzZ5fOj1s7e3CHBrvVoLGIaSDoODATrHZSfK6xEDoERAA)

However, we lied. Notice that in the above code, the `myClone` object was created without `a` being initialized.

```tsx
console.log(myObject); // { a: 123 }
console.log(myClone); // {}
console.log(myClone instanceof MyObject); // true
```

This creates what is known as a *type-hole*: the Typescript compiler will not report any bugs when we try to use `myClone.a`.  That’s because we used `Object.create` which returns the `any` type. In the above example, if we tried to use `myClone.a` in a case where we expected a `number`, but got `undefined`, we can end up with runtime bugs that should have been caught by the compiler.

We can make the typings a little more clear by doing the following:

```tsx
function inherit<T extends object>(obj: T): Partial<T> {
    return Object.create(obj);
}
```

Now Typescript will report that the value of `myClone.a` might be undefined.

Let’s improve this a bit more and create an object that inherits and freezes the data in the given object:

```tsx
function inheritAndFreeze<T extends object>(obj: T, values: Partial<T>): Readonly<Partial<T>> {
    const properties: PropertyDescriptorMap = {};

    Object.keys(obj).forEach((unsafeKey) => {
        const key = unsafeKey as keyof T;
        properties[key] = {
            value: values[key] ?? undefined,
            writable: false,
            configurable: false,
        };
    })

    return Object.create(obj, properties);
}

class MyObject {
    public a: number;

    constructor(a: number) {
        this.a = a;
    }
}

const myObject = new MyObject(123);
const myClone = inheritAndFreeze(myObject, { a: 123 });

console.log(myClone); // { a: 123 }
myClone.a = 999; // Would throw "Cannot assign to read only property 'a' of object '#<MyObject>' "
```

[Playground Link](https://www.typescriptlang.org/play?ssl=29&ssc=102&pln=1&pc=1#code/GYVwdgxgLglg9mABDMALApgJxlAgmAEwDFN10AvdAHgBVF0APKdQgZ0TgCMArdaAPgAUXbgC5ENADSIAbgEMANiHStxABTmZYi2vwCU4gEro5BBAoCeVDVpg6a-fogDeAKEQfEEBKyiIADphw-liwKupBIVoWACIqENj+UHCYALJy-ogAvC4AvgDcru6eAPI8fFAAdADW6Baswjx6lcApAKJyEKiCguCscsDoANJ1etlObp5TXj5+tRbZiH0Dw3WIcuzzcMAShdOegcGhMCoA2vMAuouT+9PySuji98qs53VXAPwfS4TowCjoAiSYq3TwAd2wUDknAUj0QwEUrHQwIAkGj0d4wP8AOYgTDQ2HiBEKJHA0EFEGIXJ6IpTUhQPFIMq8aCVBImZiNbjSQ5RMKsPSFXJFCAKDbsVIWZkVFyU-wgGEwCDrcRgEAAW04WEKlMxvkwIGgKUEclVGq1mDGN32UFQMFYlTkizke08wuFrj1fnVUvK0EWYHQYMQkul0EEAEYAEwAZkFntmiB9AGEFAh0IsUBhIfhiKQKOhBD6w1BpM4VYhozGqfGE2BWHBYZU09iixZU+nBYgAPTdkO+ll+ZzCvWN9DNuCtlNpwOOru9yux1wL6fpx2LACcW-yPb7AHU4CAFARELagsGAETJuRgMBwPzimDYpDJRCkUwcMCWAKRUILADkcj-hwOwiDK-4AMRUKGfpQPwwEXkAA)

If we didn’t mark the return value as `Readonly<Partial<T>>`, and instead just had `Partial<T>` we would once again have a type-hole and `myClone.a = 999;` would be allowed by Typescript, but would throw an exception at runtime because property a is read only as a runtime constraint.

## The Takeaway

Let’s step back and really look at what `inherit` was doing. All it gave us was a template object, and if you read on [MDN about Inheritance and prototype chaining](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain):

> You may also see some legacy code using `[Object.create()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create)` to build the inheritance chain. However, because this reassigns the `prototype` property and removes the `[constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/constructor)` property, it can be more error-prone, while performance gains may not be apparent if the constructors haven't created any instances yet.

The key here is to be wary of using utility functions built into the language that return the `any` type. Be careful what the Typescript constraints are and make sure you don’t have any type-holes when you are using these generic functions.


Forbidden Typescript: Using Object.create to clone

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    h2: "h2",
    p: "p",
    pre: "pre",
    strong: "strong",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsxs(_components.p, {
      children: ["In ", _jsx(_components.a, {
        href: "https://amzn.to/3rV5Xov",
        children: "“JavaScript: The Definitive Guide”"
      }), ", there are functions described in ", _jsx(_components.strong, {
        children: "6.5 Enumerating Properties"
      }), " that probably shouldn’t be used in production code because they modify their input parameters: ", _jsx(_components.code, {
        children: "extend"
      }), ", ", _jsx(_components.code, {
        children: "merge"
      }), ", ", _jsx(_components.code, {
        children: "restrict"
      }), ", and ", _jsx(_components.code, {
        children: "subtract"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "Let’s re-create each one using more modern practices in Typescript that don’t modify the input parameters:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "/**\n * Create a new object that returns the properties of target, overwritten with the properties in props\n */\nfunction extend<T extends object, P extends object>(target: T, props: P): T & P {\n    return {...target, ...props};\n}\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Even in a more modern implementation, I would never recommend this. It is almost always easier to write ", _jsx(_components.code, {
        children: "{...a, ...b}"
      }), " inline and have its meaning be more clear."]
    }), "\n", _jsx(_components.p, {
      children: "Next we have merge, not to be confused with extend:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "/**\n * Create a new object that returns all the properties of target and props, but the properties\n * in target are left alone.\n */\nfunction merge<T extends object, P extends object>(target: T, props: P): T & P {\n    return {...props, ...target};\n}\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Same thing here, even with a more type-safe implementation, it’s almost always more clear to have an inline spread of ", _jsx(_components.code, {
        children: "{...b, ...a}"
      }), "."]
    }), "\n", _jsxs(_components.p, {
      children: ["A more interesting function implementation is ", _jsx(_components.code, {
        children: "restrict"
      }), ":"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "/**\n * Create a new object that returns all the values in target that also exist in props.\n */\nfunction restrict<P extends object, T extends P>(target: T, props: P): Pick<T, keyof P> {\n    const t: Partial<T> = { ...target };\n\n    for (let key in target) {\n        if (!(key in props)) {\n            delete t[key];\n        }\n    }\n\n    return t as Pick<T, keyof P>;\n}\n\nconst obj1 = { a: 123, b: 222 };\nconst obj2 = { b: 0 };\n\nconsole.log(restrict(obj1, obj2)); // { b: 222 }\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Here we end up cloning our target object in order to delete keys from it later. An alternative approach might be to only construct the object with keys in props in the first place. This implementation is at least type-safe and will give you the correct typings for the object returned from ", _jsx(_components.code, {
        children: "restrict"
      }), "."]
    }), "\n", _jsxs(_components.p, {
      children: ["Lastly, here is our type-safe version of ", _jsx(_components.code, {
        children: "subtract"
      }), ":"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "/**\n * Create a new object that returns all the values in target that do not exist in props.\n */\nfunction subtract<T extends object, P extends object>(target: T, props: P): Omit<T, keyof P> {\n    const t: Partial<T> = { ...target };\n\n    for (let key in props) {\n        if (key in t) {\n            delete t[key as unknown as keyof T];\n        }\n    }\n\n    return t as Omit<T, keyof P>;\n}\n\nconsole.log(subtract(obj1, obj2)); // { a: 123 }\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Both the ", _jsx(_components.code, {
        children: "restrict"
      }), " and ", _jsx(_components.code, {
        children: "subtract"
      }), " make use of type assertions to tell the compiler we know the actual types of the objects and keys when we are removing keys. Without these assertions, ", _jsx(_components.code, {
        children: "t"
      }), " is still a ", _jsx(_components.code, {
        children: "Partial<T>"
      }), ", even after we delete the keys from the object."]
    }), "\n", _jsx(_components.h2, {
      children: "Takeaway"
    }), "\n", _jsxs(_components.p, {
      children: ["It’s almost always more clear and more type-safe to merge objects using inline spread notation than trying to use a clever utility. There are cases though, like ", _jsx(_components.code, {
        children: "restrict"
      }), " and ", _jsx(_components.code, {
        children: "subtract"
      }), " where we can leverage the type system to write safer code. There is always a balance to find when trying to write utilities between making something easier for engineers, and adding additional compile time safety."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>In <a href="https://amzn.to/3rV5Xov">“JavaScript: The Definitive Guide”</a>, there are functions described in <strong>6.5 Enumerating Properties</strong> that probably shouldn’t be used in production code because they modify their input parameters: <code>extend</code>, <code>merge</code>, <code>restrict</code>, and <code>subtract</code>.</p>
<p>Let’s re-create each one using more modern practices in Typescript that don’t modify the input parameters:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">/**
 * Create a new object that returns the properties of target, overwritten with the properties in props
 */
function extend&lt;T extends object, P extends object&gt;(target: T, props: P): T &amp; P {
    return {...target, ...props};
}
</code></pre></div>
<p>Even in a more modern implementation, I would never recommend this. It is almost always easier to write <code>{...a, ...b}</code> inline and have its meaning be more clear.</p>
<p>Next we have merge, not to be confused with extend:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">/**
 * Create a new object that returns all the properties of target and props, but the properties
 * in target are left alone.
 */
function merge&lt;T extends object, P extends object&gt;(target: T, props: P): T &amp; P {
    return {...props, ...target};
}
</code></pre></div>
<p>Same thing here, even with a more type-safe implementation, it’s almost always more clear to have an inline spread of <code>{...b, ...a}</code>.</p>
<p>A more interesting function implementation is <code>restrict</code>:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">/**
 * Create a new object that returns all the values in target that also exist in props.
 */
function restrict&lt;P extends object, T extends P&gt;(target: T, props: P): Pick&lt;T, keyof P&gt; {
    const t: Partial&lt;T&gt; = { ...target };

    for (let key in target) {
        if (!(key in props)) {
            delete t[key];
        }
    }

    return t as Pick&lt;T, keyof P&gt;;
}

const obj1 = { a: 123, b: 222 };
const obj2 = { b: 0 };

console.log(restrict(obj1, obj2)); // { b: 222 }
</code></pre></div>
<p>Here we end up cloning our target object in order to delete keys from it later. An alternative approach might be to only construct the object with keys in props in the first place. This implementation is at least type-safe and will give you the correct typings for the object returned from <code>restrict</code>.</p>
<p>Lastly, here is our type-safe version of <code>subtract</code>:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">/**
 * Create a new object that returns all the values in target that do not exist in props.
 */
function subtract&lt;T extends object, P extends object&gt;(target: T, props: P): Omit&lt;T, keyof P&gt; {
    const t: Partial&lt;T&gt; = { ...target };

    for (let key in props) {
        if (key in t) {
            delete t[key as unknown as keyof T];
        }
    }

    return t as Omit&lt;T, keyof P&gt;;
}

console.log(subtract(obj1, obj2)); // { a: 123 }
</code></pre></div>
<p>Both the <code>restrict</code> and <code>subtract</code> make use of type assertions to tell the compiler we know the actual types of the objects and keys when we are removing keys. Without these assertions, <code>t</code> is still a <code>Partial&lt;T&gt;</code>, even after we delete the keys from the object.</p>
<h2>Takeaway</h2>
<p>It’s almost always more clear and more type-safe to merge objects using inline spread notation than trying to use a clever utility. There are cases though, like <code>restrict</code> and <code>subtract</code> where we can leverage the type system to write safer code. There is always a balance to find when trying to write utilities between making something easier for engineers, and adding additional compile time safety.</p>


In [“JavaScript: The Definitive Guide”](https://amzn.to/3rV5Xov), there are functions described in **6.5 Enumerating Properties** that probably shouldn’t be used in production code because they modify their input parameters: `extend`, `merge`, `restrict`, and `subtract`.

Let’s re-create each one using more modern practices in Typescript that don’t modify the input parameters:

```tsx
/**
 * Create a new object that returns the properties of target, overwritten with the properties in props
 */
function extend<T extends object, P extends object>(target: T, props: P): T & P {
    return {...target, ...props};
}
```

Even in a more modern implementation, I would never recommend this. It is almost always easier to write `{...a, ...b}` inline and have its meaning be more clear.

Next we have merge, not to be confused with extend:

```tsx
/**
 * Create a new object that returns all the properties of target and props, but the properties
 * in target are left alone.
 */
function merge<T extends object, P extends object>(target: T, props: P): T & P {
    return {...props, ...target};
}
```

Same thing here, even with a more type-safe implementation, it’s almost always more clear to have an inline spread of `{...b, ...a}`.

A more interesting function implementation is `restrict`:

```tsx
/**
 * Create a new object that returns all the values in target that also exist in props.
 */
function restrict<P extends object, T extends P>(target: T, props: P): Pick<T, keyof P> {
    const t: Partial<T> = { ...target };

    for (let key in target) {
        if (!(key in props)) {
            delete t[key];
        }
    }

    return t as Pick<T, keyof P>;
}

const obj1 = { a: 123, b: 222 };
const obj2 = { b: 0 };

console.log(restrict(obj1, obj2)); // { b: 222 }
```

Here we end up cloning our target object in order to delete keys from it later. An alternative approach might be to only construct the object with keys in props in the first place. This implementation is at least type-safe and will give you the correct typings for the object returned from `restrict`.

Lastly, here is our type-safe version of `subtract`:

```tsx
/**
 * Create a new object that returns all the values in target that do not exist in props.
 */
function subtract<T extends object, P extends object>(target: T, props: P): Omit<T, keyof P> {
    const t: Partial<T> = { ...target };

    for (let key in props) {
        if (key in t) {
            delete t[key as unknown as keyof T];
        }
    }

    return t as Omit<T, keyof P>;
}

console.log(subtract(obj1, obj2)); // { a: 123 }
```

Both the `restrict` and `subtract` make use of type assertions to tell the compiler we know the actual types of the objects and keys when we are removing keys. Without these assertions, `t` is still a `Partial<T>`, even after we delete the keys from the object.

## Takeaway

It’s almost always more clear and more type-safe to merge objects using inline spread notation than trying to use a clever utility. There are cases though, like `restrict` and `subtract` where we can leverage the type system to write safer code. There is always a balance to find when trying to write utilities between making something easier for engineers, and adding additional compile time safety.


Forbidden Typescript: Enumerating Properties

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    h2: "h2",
    p: "p",
    pre: "pre",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsxs(_components.p, {
      children: ["We don’t get a lot of information using ", _jsx(_components.code, {
        children: "typeof"
      }), " in JavaScript or TypeScript. At most, it tells us whether a value is ", _jsx(_components.code, {
        children: "undefined"
      }), ", ", _jsx(_components.code, {
        children: "number"
      }), ", ", _jsx(_components.code, {
        children: "string"
      }), ", or ", _jsx(_components.code, {
        children: "object"
      }), ". If you want to get the class name using a function, you can use the following extended version of ", _jsx(_components.code, {
        children: "classOf"
      }), " that is originally from “JavaScript: The Definitive Guide”:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function classOf(obj: unknown) {\n    if (obj === null) return \"Null\";\n    if (typeof obj === \"undefined\") return \"Undefined\";\n\n    if (typeof obj === 'object') {\n        // Warning: this won't work if your Typescript is minified and class names are mangled.\n        return (obj as object).constructor.name;\n    }\n\n    if (typeof obj === 'function') {\n        // Warning: this won't work if your Typescript is minified and function names are mangled.\n        const possibleName = (obj as CallableFunction).name;\n        if (possibleName) {\n            return possibleName;\n        }\n    }\n\n    return Object.prototype.toString.call(obj).slice(8, -1);\n}\n\nconsole.log(classOf(null)); // \"Null\"\nconsole.log(classOf(undefined)); // \"Undefined\"\nconsole.log(classOf(1)); // \"Number\"\nconsole.log(classOf(\"foobar\")); // \"String\"\nconsole.log(classOf({})); // \"Object\"\nconsole.log(classOf([])); // \"Array\"\nconsole.log(classOf(new Date()))\n\nclass Test {}\nconsole.log(classOf(new Test())); // \"Test\"\n\nfunction test() {}\nconsole.log(classOf(test)); // \"test\"\n\nconsole.log(classOf(function () {})) // \"Function\"\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABBANgQwM4YPLABRwBGAVgFyLgDWYcA7mAJSIDeAUIh4jMIgSYgF4hiMCBQomAJwCmUEJKQAiAHJiUigNztO3XlACeAB2lweRYoOGLwAE2nAYYaTcVTZ8pQFUwdh05da2hy6eAbGpojmlgKIAOTm0tCxTGycaYgA9BmIAOpoCo4A5uRQABYwGIi0CLFQVXCSlFw8+nDyiAAqRtIYEJIwhnUViAC2jtwwzohoPsjoWCJoIz3TMqMzhSjOAHRB6TJyCrxRmJEkiVAM2xAIGFCSINAN22BL0lppAL6seyFhJmZ+EIYrFQJBYDUUns0llcvkwEUSuVKtUwLV6o1mohWu0usZev1BlxKmMEQ4pjMbIgwdB4EhXstKvlpOswJsdtDODcwHdEIY4FgYIQtso3oJjvxTgBhNDiNDC6QAMXAtIQVwZ705wR4eH5goVouWUPSJsQBw8fIFGCFIreH1N3y+PzS5qO2HO0G2hkkcCgvu62z9AGV7kVrrKUHxiFcMCgYBBpHgABwAGkQAFoAIwMLTfVjcjBwLbbFBwQp4VCYHD4UTiBg5zLZFRqRT525F6QlssV+bVvC2eyOZz1jSNxCKby+IcuNs8jtd8uVrC4PDZhuw5sjQjSSStgvz0uL3srxTAOBEfKuddNkP9Nl79vFw89qsr5ifEdjxTu4gXB9zp9uyXPsAG0AF1Pw3ABBSRJDQfR-0LQCj1fGtpFoRAABE0CgRN6wYH5gM6Ho6nfWckM7Z9gJXJwMI6Ei8Hw0cN3ou5W1YGkISQXC7kYlhvn3ZCX2XfAeMua9xzE9jBMooDj3wTi6V4FIPyYDdlXBOlFCAA",
        children: "Playground Link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["This ", _jsx(_components.code, {
        children: "classOf"
      }), " function works for any value, including numbers, strings, booleans, classes, and functions. It will return the best name for that given value that is passed. If the object has a constructor name, that value will be returned. If that value is a function, the name of that function will be returned."]
    }), "\n", _jsx(_components.h2, {
      children: "Takeaways"
    }), "\n", _jsxs(_components.p, {
      children: ["Unfortunately, during some transpilation steps or code compression, these names get mangled or removed completely, so it’s best not to rely on the class’s actual name directly. Instead ", _jsx(_components.code, {
        children: "instanceof"
      }), " should be used, or a static name attribute that cannot be modified."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>We don’t get a lot of information using <code>typeof</code> in JavaScript or TypeScript. At most, it tells us whether a value is <code>undefined</code>, <code>number</code>, <code>string</code>, or <code>object</code>. If you want to get the class name using a function, you can use the following extended version of <code>classOf</code> that is originally from “JavaScript: The Definitive Guide”:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">function classOf(obj: unknown) {
    if (obj === null) return &quot;Null&quot;;
    if (typeof obj === &quot;undefined&quot;) return &quot;Undefined&quot;;

    if (typeof obj === &#x27;object&#x27;) {
        // Warning: this won&#x27;t work if your Typescript is minified and class names are mangled.
        return (obj as object).constructor.name;
    }

    if (typeof obj === &#x27;function&#x27;) {
        // Warning: this won&#x27;t work if your Typescript is minified and function names are mangled.
        const possibleName = (obj as CallableFunction).name;
        if (possibleName) {
            return possibleName;
        }
    }

    return Object.prototype.toString.call(obj).slice(8, -1);
}

console.log(classOf(null)); // &quot;Null&quot;
console.log(classOf(undefined)); // &quot;Undefined&quot;
console.log(classOf(1)); // &quot;Number&quot;
console.log(classOf(&quot;foobar&quot;)); // &quot;String&quot;
console.log(classOf({})); // &quot;Object&quot;
console.log(classOf([])); // &quot;Array&quot;
console.log(classOf(new Date()))

class Test {}
console.log(classOf(new Test())); // &quot;Test&quot;

function test() {}
console.log(classOf(test)); // &quot;test&quot;

console.log(classOf(function () {})) // &quot;Function&quot;
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABBANgQwM4YPLABRwBGAVgFyLgDWYcA7mAJSIDeAUIh4jMIgSYgF4hiMCBQomAJwCmUEJKQAiAHJiUigNztO3XlACeAB2lweRYoOGLwAE2nAYYaTcVTZ8pQFUwdh05da2hy6eAbGpojmlgKIAOTm0tCxTGycaYgA9BmIAOpoCo4A5uRQABYwGIi0CLFQVXCSlFw8+nDyiAAqRtIYEJIwhnUViAC2jtwwzohoPsjoWCJoIz3TMqMzhSjOAHRB6TJyCrxRmJEkiVAM2xAIGFCSINAN22BL0lppAL6seyFhJmZ+EIYrFQJBYDUUns0llcvkwEUSuVKtUwLV6o1mohWu0usZev1BlxKmMEQ4pjMbIgwdB4EhXstKvlpOswJsdtDODcwHdEIY4FgYIQtso3oJjvxTgBhNDiNDC6QAMXAtIQVwZ705wR4eH5goVouWUPSJsQBw8fIFGCFIreH1N3y+PzS5qO2HO0G2hkkcCgvu62z9AGV7kVrrKUHxiFcMCgYBBpHgABwAGkQAFoAIwMLTfVjcjBwLbbFBwQp4VCYHD4UTiBg5zLZFRqRT525F6QlssV+bVvC2eyOZz1jSNxCKby+IcuNs8jtd8uVrC4PDZhuw5sjQjSSStgvz0uL3srxTAOBEfKuddNkP9Nl79vFw89qsr5ifEdjxTu4gXB9zp9uyXPsAG0AF1Pw3ABBSRJDQfR-0LQCj1fGtpFoRAABE0CgRN6wYH5gM6Ho6nfWckM7Z9gJXJwMI6Ei8Hw0cN3ou5W1YGkISQXC7kYlhvn3ZCX2XfAeMua9xzE9jBMooDj3wTi6V4FIPyYDdlXBOlFCAA">Playground Link</a></p>
<p>This <code>classOf</code> function works for any value, including numbers, strings, booleans, classes, and functions. It will return the best name for that given value that is passed. If the object has a constructor name, that value will be returned. If that value is a function, the name of that function will be returned.</p>
<h2>Takeaways</h2>
<p>Unfortunately, during some transpilation steps or code compression, these names get mangled or removed completely, so it’s best not to rely on the class’s actual name directly. Instead <code>instanceof</code> should be used, or a static name attribute that cannot be modified.</p>


We don’t get a lot of information using `typeof` in JavaScript or TypeScript. At most, it tells us whether a value is `undefined`, `number`, `string`, or `object`. If you want to get the class name using a function, you can use the following extended version of `classOf` that is originally from “JavaScript: The Definitive Guide”:

```tsx
function classOf(obj: unknown) {
    if (obj === null) return "Null";
    if (typeof obj === "undefined") return "Undefined";

    if (typeof obj === 'object') {
        // Warning: this won't work if your Typescript is minified and class names are mangled.
        return (obj as object).constructor.name;
    }

    if (typeof obj === 'function') {
        // Warning: this won't work if your Typescript is minified and function names are mangled.
        const possibleName = (obj as CallableFunction).name;
        if (possibleName) {
            return possibleName;
        }
    }

    return Object.prototype.toString.call(obj).slice(8, -1);
}

console.log(classOf(null)); // "Null"
console.log(classOf(undefined)); // "Undefined"
console.log(classOf(1)); // "Number"
console.log(classOf("foobar")); // "String"
console.log(classOf({})); // "Object"
console.log(classOf([])); // "Array"
console.log(classOf(new Date()))

class Test {}
console.log(classOf(new Test())); // "Test"

function test() {}
console.log(classOf(test)); // "test"

console.log(classOf(function () {})) // "Function"
```

[Playground Link](https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABBANgQwM4YPLABRwBGAVgFyLgDWYcA7mAJSIDeAUIh4jMIgSYgF4hiMCBQomAJwCmUEJKQAiAHJiUigNztO3XlACeAB2lweRYoOGLwAE2nAYYaTcVTZ8pQFUwdh05da2hy6eAbGpojmlgKIAOTm0tCxTGycaYgA9BmIAOpoCo4A5uRQABYwGIi0CLFQVXCSlFw8+nDyiAAqRtIYEJIwhnUViAC2jtwwzohoPsjoWCJoIz3TMqMzhSjOAHRB6TJyCrxRmJEkiVAM2xAIGFCSINAN22BL0lppAL6seyFhJmZ+EIYrFQJBYDUUns0llcvkwEUSuVKtUwLV6o1mohWu0usZev1BlxKmMEQ4pjMbIgwdB4EhXstKvlpOswJsdtDODcwHdEIY4FgYIQtso3oJjvxTgBhNDiNDC6QAMXAtIQVwZ705wR4eH5goVouWUPSJsQBw8fIFGCFIreH1N3y+PzS5qO2HO0G2hkkcCgvu62z9AGV7kVrrKUHxiFcMCgYBBpHgABwAGkQAFoAIwMLTfVjcjBwLbbFBwQp4VCYHD4UTiBg5zLZFRqRT525F6QlssV+bVvC2eyOZz1jSNxCKby+IcuNs8jtd8uVrC4PDZhuw5sjQjSSStgvz0uL3srxTAOBEfKuddNkP9Nl79vFw89qsr5ifEdjxTu4gXB9zp9uyXPsAG0AF1Pw3ABBSRJDQfR-0LQCj1fGtpFoRAABE0CgRN6wYH5gM6Ho6nfWckM7Z9gJXJwMI6Ei8Hw0cN3ou5W1YGkISQXC7kYlhvn3ZCX2XfAeMua9xzE9jBMooDj3wTi6V4FIPyYDdlXBOlFCAA)

This `classOf` function works for any value, including numbers, strings, booleans, classes, and functions. It will return the best name for that given value that is passed. If the object has a constructor name, that value will be returned. If that value is a function, the name of that function will be returned.

## Takeaways

Unfortunately, during some transpilation steps or code compression, these names get mangled or removed completely, so it’s best not to rely on the class’s actual name directly. Instead `instanceof` should be used, or a static name attribute that cannot be modified.


Forbidden Typescript: Get Class Name

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    h2: "h2",
    p: "p",
    pre: "pre",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "When creating more complex systems, there are times where you will want to ensure that an array contains every value of a defined type. We have a union of primitive literal types to define the possible values a type can have:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "type Colors = 'red' | 'green' | 'blue';\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Then, throughout our codebase, we can use the ", _jsx(_components.code, {
        children: "Color"
      }), " type to ensure functions can only be called with those values:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "addColor(name: Colors);\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "But, we may want to make sure that when we create a new possible value for the type, we don’t forget to use that value to do some initialization:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function initColors() {\n  addColor('red')\n  addColor('green');\n  addColor('blue');\n}\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "There are a few ways to do this, one would be to create a record that must contain every color:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "const allColors: Record<Colors, boolean> = {\n    red: true,\n    green: true,\n    blue: true,\n};\n\nfunction initColorsUsingRecord() {\n    (Object.keys(allColors) as Colors[]).forEach((color) => {\n        addColor(color);\n    });\n}\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["In the above snippet, we create a record that will have every ", _jsx(_components.code, {
        children: "Colors"
      }), " type as a key, and Typescript will complain when we add a new literal type to the ", _jsx(_components.code, {
        children: "Colors"
      }), " union and forget to add it to the record."]
    }), "\n", _jsxs(_components.p, {
      children: ["Notice though that we end up just getting the list of keys in ", _jsx(_components.code, {
        children: "allColors"
      }), " as an array anyway, then casting that type to help with the type-hinting for ", _jsx(_components.code, {
        children: "Object.keys"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "We can also ensure that we create an array with every value of a given type:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "/**\n * Generator function to create functions that will throw typing exceptions when\n * the given array does not contain all values of the type\n */\nfunction ensureAllOf<T>() {\n    return <U extends T[]>(array: U & ([T] extends [U[number]] ? unknown : \"Invalid\")) => array;\n}\n\ntype Color = 'red' | 'green' | 'blue';\nconst ensureAllColors = ensureAllOf<Color>();\nconst colors = ensureAllColors(['red', 'green', 'blue']);\n\nfunction addColor(color: Color) {\n    // just a stub\n}\n\nfunction initColorsUsingEnsure() {\n    colors.forEach(color => {\n        addColor(color);\n    });\n}\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/PQKhCgAIUhxBTAdvATgQwC4HsWQGYCuiAxhgJZaKTaTErybz5GkWIDO1AFppAO5kANoO4osfagE8ADmUQBzSPAAexeNPKVOfLkigwMuyPLIA3JJDQp0kyABMs8ToiwZalDGjmXhkU2kECJ0gsPG4mDBl4fWBwQhJNKiR2AnoAQWEAeTwAHgAVAD4ACgBKSABvKEhq+gxUqhyAVSVlDCQ7TjyAbQBdYqsbAC5IZoAySCKuvJ6WtsQOyC7GrsQCAFsAI1QemYB+SCIAaxc+KmGAIgBJRH9BMjtzkrKAXgLLazRJAG5wAF9wcCRaRMADCWEEOEgz0gAHJ6HYYZAAD6w+T0JCIlEwjaBeAwn7ELRuZKpeAZQRgiEoTjQknpLK5Sk4YolAlE9xUmlKDik8lM6mTOHwBEAGlR6MQMLF2NxMJ6rIB8VYlEsdjs-KKhKpw35ZUq1WqwGAkAAVgR2G40JALQQNn9FSxEpA5GQMPz2I12HJ5ABRHn0UoVKrVLU4dgAOjwOB9aGIXE14MhryDBtTqvViZQCapCtTvwVvyAA",
        children: "Typescript Playground"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["In the above example, we have a template ", _jsx(_components.code, {
        children: "ensureAllOf"
      }), " that takes a type and spits out a function that takes an array of that type and will throw a typing error if that array does not contain all of the possible values."]
    }), "\n", _jsxs(_components.p, {
      children: ["If we add “yellow” to the ", _jsx(_components.code, {
        children: "Colors"
      }), " type, then ", _jsx(_components.code, {
        children: "ensureAllColors"
      }), " will remind us that we need to add “yellow” to the list of values"]
    }), "\n", _jsx(_components.h2, {
      children: "Takeaway"
    }), "\n", _jsxs(_components.p, {
      children: ["While ", _jsx(_components.code, {
        children: "ensureAllOf"
      }), " may come in handy in some cases, it is almost always easier to use an enumeration:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "enum Color {\n    red = 'red',\n    green = 'green',\n    blue = 'blue'\n}\n\nfunction addColor(color: Color) {\n    console.log('init', color);\n}\n\nconst colors = Object.values(Color);\n\nfunction initColorsUsingEnsure() {\n    colors.forEach(color => {\n        addColor(color);\n    });\n}\ninitColorsUsingEnsure();\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/KYOwrgtgBAwg9gGzgJygbwFBW1ZwAmUAvFAOR76kA0WOA5nqMWQ8KNbdgEYJjDOkefUhgC+GDADMwIAMYAXAJZwQUAIb588JMgAUsxCgBcsQ8gCU6TlAMgAzomAA6JHV2lFIRfOo2z5gG4xCVs7eT8dO2YAeS4AK2AFJwA3NV5gO11tFECJaTklFShPb2zkOwBVO086AFF7MDxdS0wcCJQ7J0kUWrVZAAt9M2IAPis2to0tMyGdXLbRXPES+TLK6pA6hqbAoA",
        children: "Typescript Playground"
      })
    }), "\n", _jsx(_components.p, {
      children: "Using an enumeration, there is no need to write a type and have to add the new value to the ensureOfAll array."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>When creating more complex systems, there are times where you will want to ensure that an array contains every value of a defined type. We have a union of primitive literal types to define the possible values a type can have:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">type Colors = &#x27;red&#x27; | &#x27;green&#x27; | &#x27;blue&#x27;;
</code></pre></div>
<p>Then, throughout our codebase, we can use the <code>Color</code> type to ensure functions can only be called with those values:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">addColor(name: Colors);
</code></pre></div>
<p>But, we may want to make sure that when we create a new possible value for the type, we don’t forget to use that value to do some initialization:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">function initColors() {
  addColor(&#x27;red&#x27;)
  addColor(&#x27;green&#x27;);
  addColor(&#x27;blue&#x27;);
}
</code></pre></div>
<p>There are a few ways to do this, one would be to create a record that must contain every color:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">const allColors: Record&lt;Colors, boolean&gt; = {
    red: true,
    green: true,
    blue: true,
};

function initColorsUsingRecord() {
    (Object.keys(allColors) as Colors[]).forEach((color) =&gt; {
        addColor(color);
    });
}
</code></pre></div>
<p>In the above snippet, we create a record that will have every <code>Colors</code> type as a key, and Typescript will complain when we add a new literal type to the <code>Colors</code> union and forget to add it to the record.</p>
<p>Notice though that we end up just getting the list of keys in <code>allColors</code> as an array anyway, then casting that type to help with the type-hinting for <code>Object.keys</code>.</p>
<p>We can also ensure that we create an array with every value of a given type:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">/**
 * Generator function to create functions that will throw typing exceptions when
 * the given array does not contain all values of the type
 */
function ensureAllOf&lt;T&gt;() {
    return &lt;U extends T[]&gt;(array: U &amp; ([T] extends [U[number]] ? unknown : &quot;Invalid&quot;)) =&gt; array;
}

type Color = &#x27;red&#x27; | &#x27;green&#x27; | &#x27;blue&#x27;;
const ensureAllColors = ensureAllOf&lt;Color&gt;();
const colors = ensureAllColors([&#x27;red&#x27;, &#x27;green&#x27;, &#x27;blue&#x27;]);

function addColor(color: Color) {
    // just a stub
}

function initColorsUsingEnsure() {
    colors.forEach(color =&gt; {
        addColor(color);
    });
}
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/PQKhCgAIUhxBTAdvATgQwC4HsWQGYCuiAxhgJZaKTaTErybz5GkWIDO1AFppAO5kANoO4osfagE8ADmUQBzSPAAexeNPKVOfLkigwMuyPLIA3JJDQp0kyABMs8ToiwZalDGjmXhkU2kECJ0gsPG4mDBl4fWBwQhJNKiR2AnoAQWEAeTwAHgAVAD4ACgBKSABvKEhq+gxUqhyAVSVlDCQ7TjyAbQBdYqsbAC5IZoAySCKuvJ6WtsQOyC7GrsQCAFsAI1QemYB+SCIAaxc+KmGAIgBJRH9BMjtzkrKAXgLLazRJAG5wAF9wcCRaRMADCWEEOEgz0gAHJ6HYYZAAD6w+T0JCIlEwjaBeAwn7ELRuZKpeAZQRgiEoTjQknpLK5Sk4YolAlE9xUmlKDik8lM6mTOHwBEAGlR6MQMLF2NxMJ6rIB8VYlEsdjs-KKhKpw35ZUq1WqwGAkAAVgR2G40JALQQNn9FSxEpA5GQMPz2I12HJ5ABRHn0UoVKrVLU4dgAOjwOB9aGIXE14MhryDBtTqvViZQCapCtTvwVvyAA">Typescript Playground</a></p>
<p>In the above example, we have a template <code>ensureAllOf</code> that takes a type and spits out a function that takes an array of that type and will throw a typing error if that array does not contain all of the possible values.</p>
<p>If we add “yellow” to the <code>Colors</code> type, then <code>ensureAllColors</code> will remind us that we need to add “yellow” to the list of values</p>
<h2>Takeaway</h2>
<p>While <code>ensureAllOf</code> may come in handy in some cases, it is almost always easier to use an enumeration:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">enum Color {
    red = &#x27;red&#x27;,
    green = &#x27;green&#x27;,
    blue = &#x27;blue&#x27;
}

function addColor(color: Color) {
    console.log(&#x27;init&#x27;, color);
}

const colors = Object.values(Color);

function initColorsUsingEnsure() {
    colors.forEach(color =&gt; {
        addColor(color);
    });
}
initColorsUsingEnsure();
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/KYOwrgtgBAwg9gGzgJygbwFBW1ZwAmUAvFAOR76kA0WOA5nqMWQ8KNbdgEYJjDOkefUhgC+GDADMwIAMYAXAJZwQUAIb588JMgAUsxCgBcsQ8gCU6TlAMgAzomAA6JHV2lFIRfOo2z5gG4xCVs7eT8dO2YAeS4AK2AFJwA3NV5gO11tFECJaTklFShPb2zkOwBVO086AFF7MDxdS0wcCJQ7J0kUWrVZAAt9M2IAPis2to0tMyGdXLbRXPES+TLK6pA6hqbAoA">Typescript Playground</a></p>
<p>Using an enumeration, there is no need to write a type and have to add the new value to the ensureOfAll array.</p>


When creating more complex systems, there are times where you will want to ensure that an array contains every value of a defined type. We have a union of primitive literal types to define the possible values a type can have:

```tsx
type Colors = 'red' | 'green' | 'blue';
```

Then, throughout our codebase, we can use the `Color` type to ensure functions can only be called with those values:

```tsx
addColor(name: Colors);
```

But, we may want to make sure that when we create a new possible value for the type, we don’t forget to use that value to do some initialization:

```tsx
function initColors() {
  addColor('red')
  addColor('green');
  addColor('blue');
}
```

There are a few ways to do this, one would be to create a record that must contain every color:

```tsx
const allColors: Record<Colors, boolean> = {
    red: true,
    green: true,
    blue: true,
};

function initColorsUsingRecord() {
    (Object.keys(allColors) as Colors[]).forEach((color) => {
        addColor(color);
    });
}
```

In the above snippet, we create a record that will have every `Colors` type as a key, and Typescript will complain when we add a new literal type to the `Colors` union and forget to add it to the record.

Notice though that we end up just getting the list of keys in `allColors` as an array anyway, then casting that type to help with the type-hinting for `Object.keys`.

We can also ensure that we create an array with every value of a given type:

```tsx
/**
 * Generator function to create functions that will throw typing exceptions when
 * the given array does not contain all values of the type
 */
function ensureAllOf<T>() {
    return <U extends T[]>(array: U & ([T] extends [U[number]] ? unknown : "Invalid")) => array;
}

type Color = 'red' | 'green' | 'blue';
const ensureAllColors = ensureAllOf<Color>();
const colors = ensureAllColors(['red', 'green', 'blue']);

function addColor(color: Color) {
    // just a stub
}

function initColorsUsingEnsure() {
    colors.forEach(color => {
        addColor(color);
    });
}
```

[Typescript Playground](https://www.typescriptlang.org/play?#code/PQKhCgAIUhxBTAdvATgQwC4HsWQGYCuiAxhgJZaKTaTErybz5GkWIDO1AFppAO5kANoO4osfagE8ADmUQBzSPAAexeNPKVOfLkigwMuyPLIA3JJDQp0kyABMs8ToiwZalDGjmXhkU2kECJ0gsPG4mDBl4fWBwQhJNKiR2AnoAQWEAeTwAHgAVAD4ACgBKSABvKEhq+gxUqhyAVSVlDCQ7TjyAbQBdYqsbAC5IZoAySCKuvJ6WtsQOyC7GrsQCAFsAI1QemYB+SCIAaxc+KmGAIgBJRH9BMjtzkrKAXgLLazRJAG5wAF9wcCRaRMADCWEEOEgz0gAHJ6HYYZAAD6w+T0JCIlEwjaBeAwn7ELRuZKpeAZQRgiEoTjQknpLK5Sk4YolAlE9xUmlKDik8lM6mTOHwBEAGlR6MQMLF2NxMJ6rIB8VYlEsdjs-KKhKpw35ZUq1WqwGAkAAVgR2G40JALQQNn9FSxEpA5GQMPz2I12HJ5ABRHn0UoVKrVLU4dgAOjwOB9aGIXE14MhryDBtTqvViZQCapCtTvwVvyAA)

In the above example, we have a template `ensureAllOf` that takes a type and spits out a function that takes an array of that type and will throw a typing error if that array does not contain all of the possible values.

If we add “yellow” to the `Colors` type, then `ensureAllColors` will remind us that we need to add “yellow” to the list of values

## Takeaway

While `ensureAllOf` may come in handy in some cases, it is almost always easier to use an enumeration:

```tsx
enum Color {
    red = 'red',
    green = 'green',
    blue = 'blue'
}

function addColor(color: Color) {
    console.log('init', color);
}

const colors = Object.values(Color);

function initColorsUsingEnsure() {
    colors.forEach(color => {
        addColor(color);
    });
}
initColorsUsingEnsure();
```

[Typescript Playground](https://www.typescriptlang.org/play?#code/KYOwrgtgBAwg9gGzgJygbwFBW1ZwAmUAvFAOR76kA0WOA5nqMWQ8KNbdgEYJjDOkefUhgC+GDADMwIAMYAXAJZwQUAIb588JMgAUsxCgBcsQ8gCU6TlAMgAzomAA6JHV2lFIRfOo2z5gG4xCVs7eT8dO2YAeS4AK2AFJwA3NV5gO11tFECJaTklFShPb2zkOwBVO086AFF7MDxdS0wcCJQ7J0kUWrVZAAt9M2IAPis2to0tMyGdXLbRXPES+TLK6pA6hqbAoA)

Using an enumeration, there is no need to write a type and have to add the new value to the ensureOfAll array.


Forbidden Typescript: ensuring all of a type

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    h2: "h2",
    p: "p",
    pre: "pre",
    strong: "strong",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "When trying to be as type-safe as possible in Typescript, there are times when you may have to dynamically construct an object. You know as a programmer that all the keys will have values, but because you have to dynamically construct the values, the type system doesn’t know that the object is complete:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "/**\n * An example interface to demonstrate\n */\ninterface KnownCodes {\n  code1: number;\n  code2: number;\n  code3: number;\n}\n\nfunction createValuesForKnownCodes(): KnownCodes {\n  const knownCodes: Partial<KnownCodes> = {};\n\n  // In a real example, these keys may come from some other object\n  // or external data\n  for (const key in ['code1', 'code2', 'code3']) {\n     knownCodes[key as keyof KnownCodes] = dynamicValue(key);\n  }\n\n  return knownCodes as KnownCodes;\n}\n\n// Stub for the example\nfunction dynamicValue(key: string) { return 0 };\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["In the above example, we know that ", _jsx(_components.code, {
        children: "knownCodes"
      }), " will have all the keys will have values for the interface ", _jsx(_components.code, {
        children: "KnownCodes"
      }), ". However, Typescript can’t infer that, so we have to cast the value."]
    }), "\n", _jsx(_components.p, {
      children: "As the function gets more complex with additional feature work, this can become brittle and lead to some type-holes where we may have accidentally forgotten to set a key."
    }), "\n", _jsx(_components.p, {
      children: "One way to get around this is to use an assert:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "type RequireAll<T> = {\n  [K in keyof T]-?: T[K];\n};\n\nfunction ensureAllRequired<T>(obj: Partial<T>, template: RequireAll<T>): asserts obj is T {\n  for (const key in template) {\n    if (obj[key] === undefined) {\n      throw new Error(`Missing required property: ${key} in ${JSON.stringify(obj)}`);\n    }\n  }\n}\n\ninterface KnownCodes {\n  code1: number;\n  code2: number;\n  code3: number;\n}\n\nconst TEMPALTE_CODES: KnownCodes = {\n  code1: -1,\n  code2: -1,\n  code3: -1,\n}\n\nfunction createValuesForKnownCodes(): KnownCodes {\n  const knownCodes: Partial<KnownCodes> = {};\n\n  // In a real example, these keys may come from some other object\n  // or external data\n  for (const key of ['code1', 'code2']) {\n     knownCodes[key as keyof KnownCodes] = dynamicValue(key);\n  }\n\n  ensureAllRequired(knownCodes, TEMPALTE_CODES);\n\n  return knownCodes;\n}\n\ncreateValuesForKnownCodes();\n\n// Stub for the example\nfunction dynamicValue(key: string) { return 0 };\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/C4TwDgpgBAShCOBXAlgJwgQQDZYDwBUA+KAXigG8AoKKAbQGkpkA7KAawhAHsAzKfALoBaAPwAufgwEBuSgF9ZlHomYBjYMi6sIzAM6J02LHCRoIAEwKEAFFwBGAKwkAFAIaoNrvEQA0UYBAAtmBYrgESJiiGOFYAlBKuuroQHrpQ9g5MafgU1FA8XKhQ1qpausDsnEysAcGhAbG5NDTIfLaOtBwgAqQkZCrmEDwsFo1Uzc3AABaoXADuUMwQCwCiqLOo1gAGALLISSwA5lDopujmUGCzkB4gEgAk5F1y1VCPAFIAygDyAHIAdOVUEdWiB2g5YnItrFZBM5Hl4fDKCwAqgeK5VNB6Mx5swAMJcQZpcZQUqDACMEmYiECdhSsNJhIgACYqTS6ahZABIMkQADMbNp9PklEopT0FXwKx2zgwABkpQB9PHfAAiK0+EmxuIJRNITUZFIkQnJPjyvNZUBNZpovIFVtNIqUKnUmlYqnQYQgADUvIgILoAGKFbVzfFM3TWeJQUPhvUk8Xldg4sO6gMudyePCxtO6YhkcgKUU0AD0JagAElWK4ThAvFAIAAPVx1CB+aYB6BdNKBVwgRmBaA8WaBKC6LiD9IdooZCDqPJl9JFJuo5j18xhVx5ApFEplCpddJ8WgAcl55JPfjPTOZJ4EYzyzTYKbjAc6VUSlW4fBzEZ6ZHMEA10CZBVF9LB-WsLoYQRYsGz0AxMBwSIzHMKCX1zPwpRleUlRVdVPhgvJ0GAAxWGfHUI1kJEPTrAJwP9IMQwwiMo0URdPlIux8kKfwpmgJsWxCCBnTUDQtCgQDgNAhiICgzgJCBI4xlrUjUFYAAGKAiyAA",
        children: "Playground link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["The above code does a ", _jsx(_components.strong, {
        children: _jsx(_components.strong, {
          children: _jsx(_components.strong, {
            children: _jsx(_components.strong, {
              children: _jsx(_components.strong, {
                children: _jsx(_components.strong, {
                  children: _jsx(_components.strong, {
                    children: "runtime"
                  })
                })
              })
            })
          })
        })
      }), " check that the object has all the keys that are defined in the template. This ensure that any missing keys are caught as well."]
    }), "\n", _jsx(_components.p, {
      children: "I have seen other examples online where only the object is passed in, but this ends up not working if the keys are not defined in the object:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "\nfunction ensureAllRequired<T>(obj: Partial<T>): asserts obj is T {\n  for (const key in obj) {\n    if (obj[key] === undefined) {\n      throw new Error(`Missing required property: ${key} in ${JSON.stringify(obj)}`);\n    }\n  }\n}\n\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "The above will let any empty object partial to pass the assert."
    }), "\n", _jsx(_components.h2, {
      children: "Takeaway"
    }), "\n", _jsx(_components.p, {
      children: "This ends up being a lot of work to do a runtime check to improve our typings, which I’m not sure is the best approach. Most of the time when we construct objects from an empty object, it’s difficult to ensure that the full object has been safely created."
    }), "\n", _jsx(_components.p, {
      children: "Since we have to create a template object anyway, it is almost always simpler to do the following:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "interface KnownCodes {\n  code1: number;\n  code2: number;\n  code3: number;\n}\n\nconst TEMPALTE_CODES: KnownCodes = {\n  code1: -1,\n  code2: -1,\n  code3: -1,\n}\n\nfunction createValuesForKnownCodes(): KnownCodes {\n  const knownCodes = { ...TEMPALTE_CODES };\n\n  // In a real example, these keys may come from some other object\n  // or external data\n  for (const key of ['code1', 'code2', 'code3']) {\n     knownCodes[key as keyof KnownCodes] = dynamicValue(key);\n  }\n\n  return knownCodes;\n}\n\ncreateValuesForKnownCodes();\n\n// Stub for the example\nfunction dynamicValue(key: string) { return 0 };\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgNIgPYHcQGEMAmEAzsgN4BQyyChEAjAFzIgCuAtgEbQDcVNdAEzM2XXv1pEAzCI7cofAL4UKtEMTDIAKgFEAsgAUAggBldAfVwB5ACI6Ays3TY8dUgF5yEuk2QBaegAabyJhfyCQiBlw4OUKGFYQBDBgDBAaKAg4SAA1OAAbVhIAMQwoZxx8ImIACgBKJ0xKty9qNQ1kAGsm12rkTzJkADoR3UNTC2s7e2RFPn4AegXkAEl0uGRMguQIAA84dgAHfIhA5DAACxIUTogAT1J2ODuBdhQYKAx2ZGIvlAxLtBkBhOAArCDJRbLMo7XaQKAgbYEbJwfgwGE1dqaW4vDAwZAAbQA5JIGESziShOTkJTpESALp1VrUajdFxVEgEnHIOCkHF4tA9DnEen9ZAEO6I9jABB5QoQGo4up8ahxaiZMCsBFdIVuJQqBBbXIFIrEUrlXXVerzJbIeyazjIdFQc5XWEHY4QeKJZKpdISqUyuVFRX3ZgaKCgADmTMGGq16QADLM+EA",
        children: "Playground link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Here we take the easy way out and clone the template and then built the object from there. Even if we forget to add a key (like ", _jsx(_components.code, {
        children: "code3"
      }), ") to our list of keys or its missing from our external data that we are using, we will be guaranteed that the return value is the correct shape and types."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>When trying to be as type-safe as possible in Typescript, there are times when you may have to dynamically construct an object. You know as a programmer that all the keys will have values, but because you have to dynamically construct the values, the type system doesn’t know that the object is complete:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">/**
 * An example interface to demonstrate
 */
interface KnownCodes {
  code1: number;
  code2: number;
  code3: number;
}

function createValuesForKnownCodes(): KnownCodes {
  const knownCodes: Partial&lt;KnownCodes&gt; = {};

  // In a real example, these keys may come from some other object
  // or external data
  for (const key in [&#x27;code1&#x27;, &#x27;code2&#x27;, &#x27;code3&#x27;]) {
     knownCodes[key as keyof KnownCodes] = dynamicValue(key);
  }

  return knownCodes as KnownCodes;
}

// Stub for the example
function dynamicValue(key: string) { return 0 };
</code></pre></div>
<p>In the above example, we know that <code>knownCodes</code> will have all the keys will have values for the interface <code>KnownCodes</code>. However, Typescript can’t infer that, so we have to cast the value.</p>
<p>As the function gets more complex with additional feature work, this can become brittle and lead to some type-holes where we may have accidentally forgotten to set a key.</p>
<p>One way to get around this is to use an assert:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">type RequireAll&lt;T&gt; = {
  [K in keyof T]-?: T[K];
};

function ensureAllRequired&lt;T&gt;(obj: Partial&lt;T&gt;, template: RequireAll&lt;T&gt;): asserts obj is T {
  for (const key in template) {
    if (obj[key] === undefined) {
      throw new Error(`Missing required property: ${key} in ${JSON.stringify(obj)}`);
    }
  }
}

interface KnownCodes {
  code1: number;
  code2: number;
  code3: number;
}

const TEMPALTE_CODES: KnownCodes = {
  code1: -1,
  code2: -1,
  code3: -1,
}

function createValuesForKnownCodes(): KnownCodes {
  const knownCodes: Partial&lt;KnownCodes&gt; = {};

  // In a real example, these keys may come from some other object
  // or external data
  for (const key of [&#x27;code1&#x27;, &#x27;code2&#x27;]) {
     knownCodes[key as keyof KnownCodes] = dynamicValue(key);
  }

  ensureAllRequired(knownCodes, TEMPALTE_CODES);

  return knownCodes;
}

createValuesForKnownCodes();

// Stub for the example
function dynamicValue(key: string) { return 0 };
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/C4TwDgpgBAShCOBXAlgJwgQQDZYDwBUA+KAXigG8AoKKAbQGkpkA7KAawhAHsAzKfALoBaAPwAufgwEBuSgF9ZlHomYBjYMi6sIzAM6J02LHCRoIAEwKEAFFwBGAKwkAFAIaoNrvEQA0UYBAAtmBYrgESJiiGOFYAlBKuuroQHrpQ9g5MafgU1FA8XKhQ1qpausDsnEysAcGhAbG5NDTIfLaOtBwgAqQkZCrmEDwsFo1Uzc3AABaoXADuUMwQCwCiqLOo1gAGALLISSwA5lDopujmUGCzkB4gEgAk5F1y1VCPAFIAygDyAHIAdOVUEdWiB2g5YnItrFZBM5Hl4fDKCwAqgeK5VNB6Mx5swAMJcQZpcZQUqDACMEmYiECdhSsNJhIgACYqTS6ahZABIMkQADMbNp9PklEopT0FXwKx2zgwABkpQB9PHfAAiK0+EmxuIJRNITUZFIkQnJPjyvNZUBNZpovIFVtNIqUKnUmlYqnQYQgADUvIgILoAGKFbVzfFM3TWeJQUPhvUk8Xldg4sO6gMudyePCxtO6YhkcgKUU0AD0JagAElWK4ThAvFAIAAPVx1CB+aYB6BdNKBVwgRmBaA8WaBKC6LiD9IdooZCDqPJl9JFJuo5j18xhVx5ApFEplCpddJ8WgAcl55JPfjPTOZJ4EYzyzTYKbjAc6VUSlW4fBzEZ6ZHMEA10CZBVF9LB-WsLoYQRYsGz0AxMBwSIzHMKCX1zPwpRleUlRVdVPhgvJ0GAAxWGfHUI1kJEPTrAJwP9IMQwwiMo0URdPlIux8kKfwpmgJsWxCCBnTUDQtCgQDgNAhiICgzgJCBI4xlrUjUFYAAGKAiyAA">Playground link</a></p>
<p>The above code does a <strong><strong><strong><strong><strong><strong><strong>runtime</strong></strong></strong></strong></strong></strong></strong> check that the object has all the keys that are defined in the template. This ensure that any missing keys are caught as well.</p>
<p>I have seen other examples online where only the object is passed in, but this ends up not working if the keys are not defined in the object:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">
function ensureAllRequired&lt;T&gt;(obj: Partial&lt;T&gt;): asserts obj is T {
  for (const key in obj) {
    if (obj[key] === undefined) {
      throw new Error(`Missing required property: ${key} in ${JSON.stringify(obj)}`);
    }
  }
}

</code></pre></div>
<p>The above will let any empty object partial to pass the assert.</p>
<h2>Takeaway</h2>
<p>This ends up being a lot of work to do a runtime check to improve our typings, which I’m not sure is the best approach. Most of the time when we construct objects from an empty object, it’s difficult to ensure that the full object has been safely created.</p>
<p>Since we have to create a template object anyway, it is almost always simpler to do the following:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">interface KnownCodes {
  code1: number;
  code2: number;
  code3: number;
}

const TEMPALTE_CODES: KnownCodes = {
  code1: -1,
  code2: -1,
  code3: -1,
}

function createValuesForKnownCodes(): KnownCodes {
  const knownCodes = { ...TEMPALTE_CODES };

  // In a real example, these keys may come from some other object
  // or external data
  for (const key of [&#x27;code1&#x27;, &#x27;code2&#x27;, &#x27;code3&#x27;]) {
     knownCodes[key as keyof KnownCodes] = dynamicValue(key);
  }

  return knownCodes;
}

createValuesForKnownCodes();

// Stub for the example
function dynamicValue(key: string) { return 0 };
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgNIgPYHcQGEMAmEAzsgN4BQyyChEAjAFzIgCuAtgEbQDcVNdAEzM2XXv1pEAzCI7cofAL4UKtEMTDIAKgFEAsgAUAggBldAfVwB5ACI6Ays3TY8dUgF5yEuk2QBaegAabyJhfyCQiBlw4OUKGFYQBDBgDBAaKAg4SAA1OAAbVhIAMQwoZxx8ImIACgBKJ0xKty9qNQ1kAGsm12rkTzJkADoR3UNTC2s7e2RFPn4AegXkAEl0uGRMguQIAA84dgAHfIhA5DAACxIUTogAT1J2ODuBdhQYKAx2ZGIvlAxLtBkBhOAArCDJRbLMo7XaQKAgbYEbJwfgwGE1dqaW4vDAwZAAbQA5JIGESziShOTkJTpESALp1VrUajdFxVEgEnHIOCkHF4tA9DnEen9ZAEO6I9jABB5QoQGo4up8ahxaiZMCsBFdIVuJQqBBbXIFIrEUrlXXVerzJbIeyazjIdFQc5XWEHY4QeKJZKpdISqUyuVFRX3ZgaKCgADmTMGGq16QADLM+EA">Playground link</a></p>
<p>Here we take the easy way out and clone the template and then built the object from there. Even if we forget to add a key (like <code>code3</code>) to our list of keys or its missing from our external data that we are using, we will be guaranteed that the return value is the correct shape and types.</p>


When trying to be as type-safe as possible in Typescript, there are times when you may have to dynamically construct an object. You know as a programmer that all the keys will have values, but because you have to dynamically construct the values, the type system doesn’t know that the object is complete:

```tsx
/**
 * An example interface to demonstrate
 */
interface KnownCodes {
  code1: number;
  code2: number;
  code3: number;
}

function createValuesForKnownCodes(): KnownCodes {
  const knownCodes: Partial<KnownCodes> = {};

  // In a real example, these keys may come from some other object
  // or external data
  for (const key in ['code1', 'code2', 'code3']) {
     knownCodes[key as keyof KnownCodes] = dynamicValue(key);
  }

  return knownCodes as KnownCodes;
}

// Stub for the example
function dynamicValue(key: string) { return 0 };
```

In the above example, we know that `knownCodes` will have all the keys will have values for the interface `KnownCodes`. However, Typescript can’t infer that, so we have to cast the value.

As the function gets more complex with additional feature work, this can become brittle and lead to some type-holes where we may have accidentally forgotten to set a key.

One way to get around this is to use an assert:

```tsx
type RequireAll<T> = {
  [K in keyof T]-?: T[K];
};

function ensureAllRequired<T>(obj: Partial<T>, template: RequireAll<T>): asserts obj is T {
  for (const key in template) {
    if (obj[key] === undefined) {
      throw new Error(`Missing required property: ${key} in ${JSON.stringify(obj)}`);
    }
  }
}

interface KnownCodes {
  code1: number;
  code2: number;
  code3: number;
}

const TEMPALTE_CODES: KnownCodes = {
  code1: -1,
  code2: -1,
  code3: -1,
}

function createValuesForKnownCodes(): KnownCodes {
  const knownCodes: Partial<KnownCodes> = {};

  // In a real example, these keys may come from some other object
  // or external data
  for (const key of ['code1', 'code2']) {
     knownCodes[key as keyof KnownCodes] = dynamicValue(key);
  }

  ensureAllRequired(knownCodes, TEMPALTE_CODES);

  return knownCodes;
}

createValuesForKnownCodes();

// Stub for the example
function dynamicValue(key: string) { return 0 };
```

[Playground link](https://www.typescriptlang.org/play?#code/C4TwDgpgBAShCOBXAlgJwgQQDZYDwBUA+KAXigG8AoKKAbQGkpkA7KAawhAHsAzKfALoBaAPwAufgwEBuSgF9ZlHomYBjYMi6sIzAM6J02LHCRoIAEwKEAFFwBGAKwkAFAIaoNrvEQA0UYBAAtmBYrgESJiiGOFYAlBKuuroQHrpQ9g5MafgU1FA8XKhQ1qpausDsnEysAcGhAbG5NDTIfLaOtBwgAqQkZCrmEDwsFo1Uzc3AABaoXADuUMwQCwCiqLOo1gAGALLISSwA5lDopujmUGCzkB4gEgAk5F1y1VCPAFIAygDyAHIAdOVUEdWiB2g5YnItrFZBM5Hl4fDKCwAqgeK5VNB6Mx5swAMJcQZpcZQUqDACMEmYiECdhSsNJhIgACYqTS6ahZABIMkQADMbNp9PklEopT0FXwKx2zgwABkpQB9PHfAAiK0+EmxuIJRNITUZFIkQnJPjyvNZUBNZpovIFVtNIqUKnUmlYqnQYQgADUvIgILoAGKFbVzfFM3TWeJQUPhvUk8Xldg4sO6gMudyePCxtO6YhkcgKUU0AD0JagAElWK4ThAvFAIAAPVx1CB+aYB6BdNKBVwgRmBaA8WaBKC6LiD9IdooZCDqPJl9JFJuo5j18xhVx5ApFEplCpddJ8WgAcl55JPfjPTOZJ4EYzyzTYKbjAc6VUSlW4fBzEZ6ZHMEA10CZBVF9LB-WsLoYQRYsGz0AxMBwSIzHMKCX1zPwpRleUlRVdVPhgvJ0GAAxWGfHUI1kJEPTrAJwP9IMQwwiMo0URdPlIux8kKfwpmgJsWxCCBnTUDQtCgQDgNAhiICgzgJCBI4xlrUjUFYAAGKAiyAA)

The above code does a **************runtime************** check that the object has all the keys that are defined in the template. This ensure that any missing keys are caught as well.

I have seen other examples online where only the object is passed in, but this ends up not working if the keys are not defined in the object:

```tsx

function ensureAllRequired<T>(obj: Partial<T>): asserts obj is T {
  for (const key in obj) {
    if (obj[key] === undefined) {
      throw new Error(`Missing required property: ${key} in ${JSON.stringify(obj)}`);
    }
  }
}

```

The above will let any empty object partial to pass the assert.

## Takeaway

This ends up being a lot of work to do a runtime check to improve our typings, which I’m not sure is the best approach. Most of the time when we construct objects from an empty object, it’s difficult to ensure that the full object has been safely created.

Since we have to create a template object anyway, it is almost always simpler to do the following:

```tsx
interface KnownCodes {
  code1: number;
  code2: number;
  code3: number;
}

const TEMPALTE_CODES: KnownCodes = {
  code1: -1,
  code2: -1,
  code3: -1,
}

function createValuesForKnownCodes(): KnownCodes {
  const knownCodes = { ...TEMPALTE_CODES };

  // In a real example, these keys may come from some other object
  // or external data
  for (const key of ['code1', 'code2', 'code3']) {
     knownCodes[key as keyof KnownCodes] = dynamicValue(key);
  }

  return knownCodes;
}

createValuesForKnownCodes();

// Stub for the example
function dynamicValue(key: string) { return 0 };
```

[Playground link](https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgNIgPYHcQGEMAmEAzsgN4BQyyChEAjAFzIgCuAtgEbQDcVNdAEzM2XXv1pEAzCI7cofAL4UKtEMTDIAKgFEAsgAUAggBldAfVwB5ACI6Ays3TY8dUgF5yEuk2QBaegAabyJhfyCQiBlw4OUKGFYQBDBgDBAaKAg4SAA1OAAbVhIAMQwoZxx8ImIACgBKJ0xKty9qNQ1kAGsm12rkTzJkADoR3UNTC2s7e2RFPn4AegXkAEl0uGRMguQIAA84dgAHfIhA5DAACxIUTogAT1J2ODuBdhQYKAx2ZGIvlAxLtBkBhOAArCDJRbLMo7XaQKAgbYEbJwfgwGE1dqaW4vDAwZAAbQA5JIGESziShOTkJTpESALp1VrUajdFxVEgEnHIOCkHF4tA9DnEen9ZAEO6I9jABB5QoQGo4up8ahxaiZMCsBFdIVuJQqBBbXIFIrEUrlXXVerzJbIeyazjIdFQc5XWEHY4QeKJZKpdISqUyuVFRX3ZgaKCgADmTMGGq16QADLM+EA)

Here we take the easy way out and clone the template and then built the object from there. Even if we forget to add a key (like `code3`) to our list of keys or its missing from our external data that we are using, we will be guaranteed that the return value is the correct shape and types.


Forbidden Typescript: full/partial objects

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    h2: "h2",
    h3: "h3",
    p: "p",
    pre: "pre",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsxs(_components.p, {
      children: ["I've discussed ", _jsx(_components.a, {
        href: "/blog/post/2023-08-14-partial-objects",
        children: "full and partial objects before on this blog"
      }), ", and in this article I'm going to investigate a common factory pattern\nin Typescript that can lead to type-holes.\nWhen writing tests or complex components, I'll often create prop factory utilities."]
    }), "\n", _jsx(_components.p, {
      children: "For tests, the goal is to create props with all the default values, except a few that may be\noveridden for a specific test case. The function signature typically looks like this:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-jsx",
        children: "function makeFoo(partial?: Partial<Foo>): Foo;\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["The expectation is that a software developer can call ", _jsx(_components.code, {
        children: "makeFoo"
      }), " and get a version of ", _jsx(_components.code, {
        children: "Foo"
      }), " that has all the defaults set to use in tests. Then, if the developer want to override a few fields to test an edge case, all they do is call ", _jsx(_components.code, {
        children: "makeFoo({ fieldA: 'special-case })"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "I’ve seen developers try to implement this a few ways, each with its pros and cons."
    }), "\n", _jsx(_components.h3, {
      children: "Spreading"
    }), "\n", _jsx(_components.p, {
      children: "The easiest way to implement this function is to just provide defaults and spread the partial:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-jsx",
        children: "interface Foo {\n  fieldA: string;\n  fieldB?: string;\n  fieldC?: boolean | null;\n}\n\nfunction makeFoo(partial?: Partial<Foo>): Foo {\n  return {\n\t  fieldA: 'test',\n    fieldB: 'example',\n    fieldC: false,\n    ...partial\n  };\n}\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Here, we create a ", _jsx(_components.code, {
        children: "Foo"
      }), "  mock with overrides for the defaults, which are provided by ", _jsx(_components.code, {
        children: "partial?: Partial<Foo>"
      }), " . However, even though ", _jsx(_components.code, {
        children: "fieldA"
      }), " is required, we can see a type-hole with the default Typescript compilation settings:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-jsx",
        children: "const instance = makeFoo({ fieldA: undefined, fieldB: undefined, fieldC: undefined });\nconsole.log(instance.fieldA);\n\n// No type error, but this blows up\nconsole.log(instance.fieldA.toLowerCase());\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["When we spread, ", _jsx(_components.code, {
        children: "undefined"
      }), " actually overrides the default! But why were we allowed to provide ", _jsx(_components.code, {
        children: "undefined"
      }), " in the first place?"]
    }), "\n", _jsxs(_components.p, {
      children: ["In Typescript, ", _jsx(_components.code, {
        children: "Partial<Foo>"
      }), "  keeps all the fields, but makes them optional. In the default compilation settings, an optional field can be set to ", _jsx(_components.code, {
        children: "undefined"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play/?#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTIAOSQ9BkANOwpnGRcNBkQAB5wFk7yeQUcYuI08CS0EPkEBAB0PS5uwB7sOrr6COb0yKD0ikjIALzIVrb2DtgNaTRGZBBEIBBkyDohbGMgtOjyXSToTA5TYDMQXamUx-oA9O-IAHJYYACeThQ0Cg6CguRk6jAyDAAAtgLQZNcAO6I9ROXCnc6Xa63e6PZ5FChdMDoAAy6GR0HEcDaDhCxyAA",
        children: "Typescript Playground Link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["There is a Typescript compilation flag to throw a type-error and keep our sanity: ", _jsx(_components.code, {
        children: "exactOptionalPropertyTypes"
      }), ". Enabling this flag makes Typescript show an error for ", _jsx(_components.code, {
        children: "makeFoo({ fieldA: undefined, fieldB: undefined, fieldC: undefined });"
      }), ". We can add the field to the call if it is set to a value."]
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTIAOSQ9BkANOwpnGRcNBkQAB5wFk7yeQUcYuI08CS0EPkEBAB0PS5uwB7sOrr6COb0yKD0ikjIALzIVrb2DtgNaTRGZBBEIBBkuevFmyDbu-uHqRInZ6D7yDohbGMgtOjyXSToTA5TYDMQLpXChPUbjd6Ar4-P4AoFFChdMDoAAy6AA7tBxHA2g4Qk8gA",
        children: "Typescript Playground Link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["But this causes another problem: it is perfectly valid to create an initial instance of ", _jsx(_components.code, {
        children: "Foo"
      }), " without fieldB being set (and its value being ", _jsx(_components.code, {
        children: "undefined"
      }), "). But now our ", _jsx(_components.code, {
        children: "makeFoo"
      }), " object doesn’t allow us to pass ", _jsx(_components.code, {
        children: "fieldB: undefined"
      }), " anymore. Only when the interface explicitly defines fieldB as optional AND undefined does it allow us to so."]
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQTZAB9kAVxBkIREBDJsCRUmQDCfZACNMJCHBCjkIcSRJsAvrlwxJCMMHQGAtnADWEDOgAUABzhR7OBINAAV-QJIAHk8APgBKGk8cdigIMHEoAzwASCVOShoAckh6QoAadjyVLiKIAA84Jx9dcsqOFVUaeBJaCAqCAgA6Yb8A4CD2cwsrBEd6ZFB6fSRkAF5kF3dPL2x27hpJaVl5ZHM4tlmQWnRdQZJ0Ji9FsGWIQeVyCnOZuZu3+8ez1e73yFEGYHQABl0AB3aCqOC9Lxxc5AA",
        children: "Typescript Playground Link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Generally this pattern without the flag is fine for creating mock data, since any type-holes would only be scoped to tests and not real production code. But the question is: can we have ", _jsx(_components.code, {
        children: "makeFoo"
      }), " take a partial, return Foo without type-holes, and have allow ", _jsx(_components.code, {
        children: "undefined"
      }), " for partials?"]
    }), "\n", _jsx(_components.h2, {
      children: "Null-Coalescing Every Field"
    }), "\n", _jsx(_components.p, {
      children: "Another common implementation I have seen is to add nullish coalescing to every field:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-jsx",
        children: "interface Foo {\n  fieldA: string;\n  fieldB?: string;\n  fieldC?: boolean | null;\n}\n\nfunction makeFoo(partial?: Partial<Foo>): Foo {\n  return {\n\t  fieldA: partial?.fieldA ?? 'test',\n    fieldB: partial?.fieldB ?? 'example',\n    fieldC: partial?.fieldC ?? false,\n  };\n} \n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Let’s also turn off the ", _jsx(_components.code, {
        children: "exactOptionalPropertyTypes"
      }), " compilation flag for now."]
    }), "\n", _jsxs(_components.p, {
      children: ["We know every field will be set correctly, so there are no type-holes in ", _jsx(_components.code, {
        children: "Foo"
      }), ", however, we still have the problem where we cannot override a field to the ", _jsx(_components.code, {
        children: "unset"
      }), " value of ", _jsx(_components.code, {
        children: "undefined"
      }), " :"]
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=false&ssl=13&ssc=2&pln=1&pc=1#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTILm7AHjwAdKmUyDw8yADkkPSlADTsKZxkXDSZfnkFXEUlpRAAHnAWTvLVtRxi4k2+2Z759eIdhB60EDUEOrr6COb0yKD0ikjIALzIVrb2DtgjaTRGZBBEIBBkVZcN1yC394-IOiFsGyC0dDyXIkdBMBw7MB7CDTMQUX64f6A4Gg8GQ6Gw7gIxGbIEw1EQgFQ4wwgoUXJgdAAGXQAHdoOI4IsHCEEUA",
        children: "Typescript Playground Link"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Turning on the ", _jsx(_components.code, {
        children: "exactOptionalPropertyTypes"
      }), " also doesn’t save us here since we didn’t have a type-issue anyway, but more of a logic issue. ", _jsx(_components.code, {
        children: "makeFoo({ fieldB: undefined })"
      }), " will still set ", _jsx(_components.code, {
        children: "fieldB"
      }), " to ", _jsx(_components.code, {
        children: "example"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "Allowing bad inputs"
    }), "\n", _jsxs(_components.p, {
      children: ["This last approach takes the first and second approaches above and combines them using a ", _jsx(_components.code, {
        children: "pickOrDefault"
      }), " function. Here if any value is passed into the partial, we will return it, except when that value would be incorrect in the output type:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function isValuePresent<T extends object>(obj: T, key: keyof T): boolean {\n    return key in obj;\n}\n\nfunction pickOrDefault<T extends object, K extends keyof T>(partial: T, key: K, fallbackValue: T[K]): T[K] {\n  if (key in partial) {\n    return partial[key];\n  }\n\n  return fallbackValue\n}\n\ninterface Foo {\n  fieldA: string;\n  fieldB?: string;\n  fieldC?: boolean | null;\n}\n\nfunction makeFoo(partial: Partial<Foo> = {}): Foo {\n  return {\n\t  fieldA: pickOrDefault(partial, 'fieldA', 'test') ?? 'test',\n    fieldB: pickOrDefault(partial, 'fieldB', 'example'),\n    fieldC: pickOrDefault(partial, 'fieldC', true),\n  };\n}\n\nconst instance = makeFoo({ fieldA: undefined, fieldB: undefined });\nconsole.log(instance.fieldA);\nconsole.log(instance.fieldB);\n\nconsole.log(instance.fieldA.toLowerCase());\n\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["For each field, we prefer the input partial, except here the type mismatch for ", _jsx(_components.code, {
        children: "fieldA"
      }), " forced us to add the default value twice, once if the partial didn’t have a value, and once if the partial had ", _jsx(_components.code, {
        children: "undefined"
      }), " which isn’t allows in the final version of ", _jsx(_components.code, {
        children: "type Foo"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "While more verbose, this does eliminate the type holes the code!"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>I&#x27;ve discussed <a href="/blog/post/2023-08-14-partial-objects">full and partial objects before on this blog</a>, and in this article I&#x27;m going to investigate a common factory pattern
in Typescript that can lead to type-holes.
When writing tests or complex components, I&#x27;ll often create prop factory utilities.</p>
<p>For tests, the goal is to create props with all the default values, except a few that may be
overidden for a specific test case. The function signature typically looks like this:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-jsx">function makeFoo(partial?: Partial&lt;Foo&gt;): Foo;
</code></pre></div>
<p>The expectation is that a software developer can call <code>makeFoo</code> and get a version of <code>Foo</code> that has all the defaults set to use in tests. Then, if the developer want to override a few fields to test an edge case, all they do is call <code>makeFoo({ fieldA: &#x27;special-case })</code>.</p>
<p>I’ve seen developers try to implement this a few ways, each with its pros and cons.</p>
<h3>Spreading</h3>
<p>The easiest way to implement this function is to just provide defaults and spread the partial:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-jsx">interface Foo {
  fieldA: string;
  fieldB?: string;
  fieldC?: boolean | null;
}

function makeFoo(partial?: Partial&lt;Foo&gt;): Foo {
  return {
	  fieldA: &#x27;test&#x27;,
    fieldB: &#x27;example&#x27;,
    fieldC: false,
    ...partial
  };
}
</code></pre></div>
<p>Here, we create a <code>Foo</code>  mock with overrides for the defaults, which are provided by <code>partial?: Partial&lt;Foo&gt;</code> . However, even though <code>fieldA</code> is required, we can see a type-hole with the default Typescript compilation settings:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-jsx">const instance = makeFoo({ fieldA: undefined, fieldB: undefined, fieldC: undefined });
console.log(instance.fieldA);

// No type error, but this blows up
console.log(instance.fieldA.toLowerCase());
</code></pre></div>
<p>When we spread, <code>undefined</code> actually overrides the default! But why were we allowed to provide <code>undefined</code> in the first place?</p>
<p>In Typescript, <code>Partial&lt;Foo&gt;</code>  keeps all the fields, but makes them optional. In the default compilation settings, an optional field can be set to <code>undefined</code>.</p>
<p><a href="https://www.typescriptlang.org/play/?#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTIAOSQ9BkANOwpnGRcNBkQAB5wFk7yeQUcYuI08CS0EPkEBAB0PS5uwB7sOrr6COb0yKD0ikjIALzIVrb2DtgNaTRGZBBEIBBkyDohbGMgtOjyXSToTA5TYDMQXamUx-oA9O-IAHJYYACeThQ0Cg6CguRk6jAyDAAAtgLQZNcAO6I9ROXCnc6Xa63e6PZ5FChdMDoAAy6GR0HEcDaDhCxyAA">Typescript Playground Link</a></p>
<p>There is a Typescript compilation flag to throw a type-error and keep our sanity: <code>exactOptionalPropertyTypes</code>. Enabling this flag makes Typescript show an error for <code>makeFoo({ fieldA: undefined, fieldB: undefined, fieldC: undefined });</code>. We can add the field to the call if it is set to a value.</p>
<p><a href="https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTIAOSQ9BkANOwpnGRcNBkQAB5wFk7yeQUcYuI08CS0EPkEBAB0PS5uwB7sOrr6COb0yKD0ikjIALzIVrb2DtgNaTRGZBBEIBBkuevFmyDbu-uHqRInZ6D7yDohbGMgtOjyXSToTA5TYDMQLpXChPUbjd6Ar4-P4AoFFChdMDoAAy6AA7tBxHA2g4Qk8gA">Typescript Playground Link</a></p>
<p>But this causes another problem: it is perfectly valid to create an initial instance of <code>Foo</code> without fieldB being set (and its value being <code>undefined</code>). But now our <code>makeFoo</code> object doesn’t allow us to pass <code>fieldB: undefined</code> anymore. Only when the interface explicitly defines fieldB as optional AND undefined does it allow us to so.</p>
<p><a href="https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQTZAB9kAVxBkIREBDJsCRUmQDCfZACNMJCHBCjkIcSRJsAvrlwxJCMMHQGAtnADWEDOgAUABzhR7OBINAAV-QJIAHk8APgBKGk8cdigIMHEoAzwASCVOShoAckh6QoAadjyVLiKIAA84Jx9dcsqOFVUaeBJaCAqCAgA6Yb8A4CD2cwsrBEd6ZFB6fSRkAF5kF3dPL2x27hpJaVl5ZHM4tlmQWnRdQZJ0Ji9FsGWIQeVyCnOZuZu3+8ez1e73yFEGYHQABl0AB3aCqOC9Lxxc5AA">Typescript Playground Link</a></p>
<p>Generally this pattern without the flag is fine for creating mock data, since any type-holes would only be scoped to tests and not real production code. But the question is: can we have <code>makeFoo</code> take a partial, return Foo without type-holes, and have allow <code>undefined</code> for partials?</p>
<h2>Null-Coalescing Every Field</h2>
<p>Another common implementation I have seen is to add nullish coalescing to every field:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-jsx">interface Foo {
  fieldA: string;
  fieldB?: string;
  fieldC?: boolean | null;
}

function makeFoo(partial?: Partial&lt;Foo&gt;): Foo {
  return {
	  fieldA: partial?.fieldA ?? &#x27;test&#x27;,
    fieldB: partial?.fieldB ?? &#x27;example&#x27;,
    fieldC: partial?.fieldC ?? false,
  };
} 
</code></pre></div>
<p>Let’s also turn off the <code>exactOptionalPropertyTypes</code> compilation flag for now.</p>
<p>We know every field will be set correctly, so there are no type-holes in <code>Foo</code>, however, we still have the problem where we cannot override a field to the <code>unset</code> value of <code>undefined</code> :</p>
<p><a href="https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=false&amp;ssl=13&amp;ssc=2&amp;pln=1&amp;pc=1#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTILm7AHjwAdKmUyDw8yADkkPSlADTsKZxkXDSZfnkFXEUlpRAAHnAWTvLVtRxi4k2+2Z759eIdhB60EDUEOrr6COb0yKD0ikjIALzIVrb2DtgjaTRGZBBEIBBkVZcN1yC394-IOiFsGyC0dDyXIkdBMBw7MB7CDTMQUX64f6A4Gg8GQ6Gw7gIxGbIEw1EQgFQ4wwgoUXJgdAAGXQAHdoOI4IsHCEEUA">Typescript Playground Link</a></p>
<p>Turning on the <code>exactOptionalPropertyTypes</code> also doesn’t save us here since we didn’t have a type-issue anyway, but more of a logic issue. <code>makeFoo({ fieldB: undefined })</code> will still set <code>fieldB</code> to <code>example</code>.</p>
<h2>Allowing bad inputs</h2>
<p>This last approach takes the first and second approaches above and combines them using a <code>pickOrDefault</code> function. Here if any value is passed into the partial, we will return it, except when that value would be incorrect in the output type:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-tsx">function isValuePresent&lt;T extends object&gt;(obj: T, key: keyof T): boolean {
    return key in obj;
}

function pickOrDefault&lt;T extends object, K extends keyof T&gt;(partial: T, key: K, fallbackValue: T[K]): T[K] {
  if (key in partial) {
    return partial[key];
  }

  return fallbackValue
}

interface Foo {
  fieldA: string;
  fieldB?: string;
  fieldC?: boolean | null;
}

function makeFoo(partial: Partial&lt;Foo&gt; = {}): Foo {
  return {
	  fieldA: pickOrDefault(partial, &#x27;fieldA&#x27;, &#x27;test&#x27;) ?? &#x27;test&#x27;,
    fieldB: pickOrDefault(partial, &#x27;fieldB&#x27;, &#x27;example&#x27;),
    fieldC: pickOrDefault(partial, &#x27;fieldC&#x27;, true),
  };
}

const instance = makeFoo({ fieldA: undefined, fieldB: undefined });
console.log(instance.fieldA);
console.log(instance.fieldB);

console.log(instance.fieldA.toLowerCase());

</code></pre></div>
<p>For each field, we prefer the input partial, except here the type mismatch for <code>fieldA</code> forced us to add the default value twice, once if the partial didn’t have a value, and once if the partial had <code>undefined</code> which isn’t allows in the final version of <code>type Foo</code>.</p>
<p>While more verbose, this does eliminate the type holes the code!</p>

I've discussed [full and partial objects before on this blog](/blog/post/2023-08-14-partial-objects), and in this article I'm going to investigate a common factory pattern
in Typescript that can lead to type-holes.
When writing tests or complex components, I'll often create prop factory utilities.



For tests, the goal is to create props with all the default values, except a few that may be
overidden for a specific test case. The function signature typically looks like this:

```jsx
function makeFoo(partial?: Partial<Foo>): Foo;
```

The expectation is that a software developer can call `makeFoo` and get a version of `Foo` that has all the defaults set to use in tests. Then, if the developer want to override a few fields to test an edge case, all they do is call `makeFoo({ fieldA: 'special-case })`.

I’ve seen developers try to implement this a few ways, each with its pros and cons.

### Spreading

The easiest way to implement this function is to just provide defaults and spread the partial:

```jsx
interface Foo {
  fieldA: string;
  fieldB?: string;
  fieldC?: boolean | null;
}

function makeFoo(partial?: Partial<Foo>): Foo {
  return {
	  fieldA: 'test',
    fieldB: 'example',
    fieldC: false,
    ...partial
  };
}
```

Here, we create a `Foo`  mock with overrides for the defaults, which are provided by `partial?: Partial<Foo>` . However, even though `fieldA` is required, we can see a type-hole with the default Typescript compilation settings:

```jsx
const instance = makeFoo({ fieldA: undefined, fieldB: undefined, fieldC: undefined });
console.log(instance.fieldA);

// No type error, but this blows up
console.log(instance.fieldA.toLowerCase());
```

When we spread, `undefined` actually overrides the default! But why were we allowed to provide `undefined` in the first place?

In Typescript, `Partial<Foo>`  keeps all the fields, but makes them optional. In the default compilation settings, an optional field can be set to `undefined`.

[Typescript Playground Link](https://www.typescriptlang.org/play/?#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTIAOSQ9BkANOwpnGRcNBkQAB5wFk7yeQUcYuI08CS0EPkEBAB0PS5uwB7sOrr6COb0yKD0ikjIALzIVrb2DtgNaTRGZBBEIBBkyDohbGMgtOjyXSToTA5TYDMQXamUx-oA9O-IAHJYYACeThQ0Cg6CguRk6jAyDAAAtgLQZNcAO6I9ROXCnc6Xa63e6PZ5FChdMDoAAy6GR0HEcDaDhCxyAA)

There is a Typescript compilation flag to throw a type-error and keep our sanity: `exactOptionalPropertyTypes`. Enabling this flag makes Typescript show an error for `makeFoo({ fieldA: undefined, fieldB: undefined, fieldC: undefined });`. We can add the field to the call if it is set to a value.

[Typescript Playground Link](https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTIAOSQ9BkANOwpnGRcNBkQAB5wFk7yeQUcYuI08CS0EPkEBAB0PS5uwB7sOrr6COb0yKD0ikjIALzIVrb2DtgNaTRGZBBEIBBkuevFmyDbu-uHqRInZ6D7yDohbGMgtOjyXSToTA5TYDMQLpXChPUbjd6Ar4-P4AoFFChdMDoAAy6AA7tBxHA2g4Qk8gA)

But this causes another problem: it is perfectly valid to create an initial instance of `Foo` without fieldB being set (and its value being `undefined`). But now our `makeFoo` object doesn’t allow us to pass `fieldB: undefined` anymore. Only when the interface explicitly defines fieldB as optional AND undefined does it allow us to so.

[Typescript Playground Link](https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQTZAB9kAVxBkIREBDJsCRUmQDCfZACNMJCHBCjkIcSRJsAvrlwxJCMMHQGAtnADWEDOgAUABzhR7OBINAAV-QJIAHk8APgBKGk8cdigIMHEoAzwASCVOShoAckh6QoAadjyVLiKIAA84Jx9dcsqOFVUaeBJaCAqCAgA6Yb8A4CD2cwsrBEd6ZFB6fSRkAF5kF3dPL2x27hpJaVl5ZHM4tlmQWnRdQZJ0Ji9FsGWIQeVyCnOZuZu3+8ez1e73yFEGYHQABl0AB3aCqOC9Lxxc5AA)

Generally this pattern without the flag is fine for creating mock data, since any type-holes would only be scoped to tests and not real production code. But the question is: can we have `makeFoo` take a partial, return Foo without type-holes, and have allow `undefined` for partials?

## Null-Coalescing Every Field

Another common implementation I have seen is to add nullish coalescing to every field:

```jsx
interface Foo {
  fieldA: string;
  fieldB?: string;
  fieldC?: boolean | null;
}

function makeFoo(partial?: Partial<Foo>): Foo {
  return {
	  fieldA: partial?.fieldA ?? 'test',
    fieldB: partial?.fieldB ?? 'example',
    fieldC: partial?.fieldC ?? false,
  };
} 
```

Let’s also turn off the `exactOptionalPropertyTypes` compilation flag for now.

We know every field will be set correctly, so there are no type-holes in `Foo`, however, we still have the problem where we cannot override a field to the `unset` value of `undefined` :

[Typescript Playground Link](https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=false&ssl=13&ssc=2&pln=1&pc=1#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIzAQA2AJgIIBcyAzmFKAOYDc+hx5AQgPw32MQrdkVJkAwn2QAjTCQhwQyAD7IQAVxIk2AX1y4Y6kAjDB0SgLZwA1hAzoAFAAc4UU3BJSACq-ckAPPYAfACUNPY47FAQYOpQSngAkASi5NTILm7AHjwAdKmUyDw8yADkkPSlADTsKZxkXDSZfnkFXEUlpRAAHnAWTvLVtRxi4k2+2Z759eIdhB60EDUEOrr6COb0yKD0ikjIALzIVrb2DtgjaTRGZBBEIBBkVZcN1yC394-IOiFsGyC0dDyXIkdBMBw7MB7CDTMQUX64f6A4Gg8GQ6Gw7gIxGbIEw1EQgFQ4wwgoUXJgdAAGXQAHdoOI4IsHCEEUA)

Turning on the `exactOptionalPropertyTypes` also doesn’t save us here since we didn’t have a type-issue anyway, but more of a logic issue. `makeFoo({ fieldB: undefined })` will still set `fieldB` to `example`.

## Allowing bad inputs

This last approach takes the first and second approaches above and combines them using a `pickOrDefault` function. Here if any value is passed into the partial, we will return it, except when that value would be incorrect in the output type:

```tsx
function isValuePresent<T extends object>(obj: T, key: keyof T): boolean {
    return key in obj;
}

function pickOrDefault<T extends object, K extends keyof T>(partial: T, key: K, fallbackValue: T[K]): T[K] {
  if (key in partial) {
    return partial[key];
  }

  return fallbackValue
}

interface Foo {
  fieldA: string;
  fieldB?: string;
  fieldC?: boolean | null;
}

function makeFoo(partial: Partial<Foo> = {}): Foo {
  return {
	  fieldA: pickOrDefault(partial, 'fieldA', 'test') ?? 'test',
    fieldB: pickOrDefault(partial, 'fieldB', 'example'),
    fieldC: pickOrDefault(partial, 'fieldC', true),
  };
}

const instance = makeFoo({ fieldA: undefined, fieldB: undefined });
console.log(instance.fieldA);
console.log(instance.fieldB);

console.log(instance.fieldA.toLowerCase());

```

For each field, we prefer the input partial, except here the type mismatch for `fieldA` forced us to add the default value twice, once if the partial didn’t have a value, and once if the partial had `undefined` which isn’t allows in the final version of `type Foo`.

While more verbose, this does eliminate the type holes the code!

Forbidden Typescript: Using Object.create to clone

Forbidden Typescript: Enumerating Properties

Forbidden Typescript: Get Class Name

Forbidden Typescript: ensuring all of a type

Forbidden Typescript: full/partial objects

Forbidden Typescript: Spreading Type-holes