typescript posts - idmontie's Portfolio

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    h2: "h2",
    a: "a",
    pre: "pre",
    code: "code"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "When building web applications, enforcing that strings be localized to the user’s preferred language can sometimes be achieved via lint rules. But what if we could enforce proper localization using types in Typescript?"
    }), "\n", _jsx(_components.h2, {
      children: "Defining a Localized Type"
    }), "\n", _jsxs(_components.p, {
      children: ["Typescript doesn’t natively provide an ", _jsx(_components.a, {
        href: "https://en.wikipedia.org/wiki/Opaque_data_type",
        children: "Opaque type"
      }), " that we can use to define a string that has already been localized. If the data looks like a string, Typescript will consider it a string. We can however use utility types that simulate opaque types, like the Opaque definition in ", _jsx(_components.a, {
        href: "https://github.com/sindresorhus/type-fest",
        children: "type-fest"
      }), ":"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "import { Opaque } from 'type-fest';\n\ntype LocalizedString = Opaque<'LocalizedString', string>;\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgeTAQwI4FcCmcC+cAZlBCHAOQwCeYOAtETgM4wUDcAUJzXXADIQAxmgA2wAF44AJgGUYUYADsA5nAC8KdNhwAeCoJHipchcpUUANHFaLVAPnZA",
        children: "Playground example"
      })
    }), "\n", _jsx(_components.p, {
      children: "Here is a short example where we create a localized string and try to use a raw string and our localized string in a function:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "import { Opaque } from 'type-fest';\n\ntype LocalizedString = Opaque<'LocalizedString', string>;\n\nfunction createLocalizedString(s: string): LocalizedString {\n    return s as LocalizedString;\n}\n\nfunction example(s: LocalizedString) {\n    return s;\n}\n\nconsole.log(example('test')); // Will throw a type error\nconsole.log(example(createLocalizedString('test'))); // Works correctly\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgeTAQwI4FcCmcC+cAZlBCHAOQwCeYOAtETgM4wUDcAUJzXXADIQAxmgA2wAF44AJgGUYUYADsA5nAC8KdNhwAeCoJHipchcpUUANHFaLVAPi6ciWJUJjAISuEKg40MDiGYpIy8nYqABTMAFw2ZqoAlHHBxmEJagiccDlwfjBYUN7McGglqaGmEVz43C5uHl5wOAAeaOCiONEpwiEm4eaJiNm5+YXFNdxCXswQnQB0ohBRre1gnZFULGyJiVzTSrMLSyttHV2+-oEV-RmbgawUu3tAA",
        children: "Playground example"
      })
    }), "\n", _jsx(_components.p, {
      children: "Now we have a type that we can use in our function and components to denote that we expect an already localized string to be used."
    }), "\n", _jsx(_components.h2, {
      children: "Enforcing in Components"
    }), "\n", _jsx(_components.p, {
      children: "The simplest way we can enforce that strings have already been localized is by using the type in our component’s props interface:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "\ninterface ButtonProps {\n  label: LocalizedString;\n}\n\nfunction Button(props: ButtonProps) {\n  return <button>{props.label}</button>;\n}\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Now if we try to use that component without a localized string, we get an error:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "import React from 'react';\nimport { Opaque } from 'type-fest';\n\ntype LocalizedString = Opaque<'LocalizedString', string>;\n\nfunction createLocalizedString(s: string): LocalizedString {\n    return s as LocalizedString;\n}\n\ninterface ButtonProps {\n  label: LocalizedString;\n}\n\nfunction Button(props: ButtonProps) {\n  return <button>{props.label}</button>;\n}\n\nfunction Example() {\n    return (\n        <>\n            <Button label=\"Test\" />\n            <Button label={createLocalizedString(\"Test\")} />\n        </>\n    );\n}\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wG4AoUSWOAbzgHkwUBHAVyTgF85tcCYATzBIAtJiQBnGGXLkhIuABkIaFABtgALyQATAMowowAHYBzOAF5GzdkgA8+FWs06DR02fwAaONOPmAHwU5JhsJhjAECZwaEQoMEjOGtp6hgFmABSSAFx+HuYAlHnJrmkFFrTkcDVwRDBsUDGScCgtpanuGRRccqaJUJjonABCbDAw0QAKOGAtVTXqKABGSOolqilu6Z49cmERMFExYxPRmWCzuXCnkyYzEHOFdNV1SA1NcPbL43eBtJdHpIAHRLVbqLj2AD0PzOJmC5F6oXCkWicAAogAPFDgdRITLPBa1eqNGKZV61Wr2QIUyl0+y3NFgtaWABEABUpDBWXAoTS6QKvoyYsz1JZaHFUIkOtsKpkOVzWYUeHzaZTofzaoUekA",
        children: "Playground example"
      })
    }), "\n", _jsx(_components.h2, {
      children: "Localizing Strings"
    }), "\n", _jsxs(_components.p, {
      children: ["So far, we’ve been using a utility ", _jsx(_components.code, {
        children: "createLocalizedString"
      }), " to create and use the LocalizedString type. This utility is only really practical in unit tests. For real applications, we’ll want to use a translation function from ", _jsx(_components.a, {
        href: "https://github.com/i18next/react-i18next",
        children: "react-i18next"
      }), " or ", _jsx(_components.a, {
        href: "https://github.com/i18next/next-i18next",
        children: "next-i18next"
      }), " to do the heavy lifting. Then we just wrap the translation functions that are provided in order to use our type:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "import React, { useCallback } from 'react';\nimport { Opaque } from 'type-fest';\nimport { useTranslation } from 'react-i18next';\n\ntype LocalizedString = Opaque<'LocalizedString', string>;\n\nfunction createLocalizedString(s: string): LocalizedString {\n    return s as LocalizedString;\n}\n\ninterface ButtonProps {\n  label: LocalizedString;\n}\n\nfunction Button(props: ButtonProps) {\n  return <button>{props.label}</button>;\n}\n\nfunction useLocalizedTranslation() {\n    const { t : originalTranslate } = useTranslation();\n\n    const t = useCallback((key: string, defaultString: string) => {\n        return originalTranslate(key, defaultString) as LocalizedString;\n    }, [originalTranslate]);\n\n    return { t };\n}\n\nfunction Example() {\n    const { t } = useLocalizedTranslation();\n    return (\n        <>\n            <Button label={t(\"test\", \"Test\")} />\n        </>\n    );\n}\n"
      })
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDGMA0cDecCuAzkgMIoA25ARugNZwC+cAZlBCHAORSoacDcAKFCRYuOAHkwKAI74kjFmw6cYATzBIAtMySEYA4eGjw8RJABUoKAHaFyKGMAg3Frdlx7oYW4AEYADhskAA8DIUF1TTgAGQg0CmAALyQAEwBlGChgGwBzOABeSWk5JAAeTjiE8mS0zOy8zmx9BtyAPgjmfBsMZ1c0LxgkKsSUjKyc3IAKQgAuOBbJgEp5kZqx+sncQThduB4YfChXQjgUU7Xa8dahBkFhGyGoZnQFACF8GBgXAAU2MFOOB2cAcVCQ5FW8VGdQmeVu9y6PScLjgHy+LimYH+c1Rn2+Nj+EABS22uwOR1cZSoeJcbRwWKJhAAdKDwQwygB6anomwdQR3QSI3oo8yXMZWWz2Rx9KYkoF7OBoFz6cTwebQYC5HIUCV2BxDRRFcy6qXImyyiIKpV2eDwI3EMiUGhoWhTKa0JBqeaLPLYVJIF74cgwTZ5b2w3IkgptUkKvbk45wDVamw66x6xxId2ev0BlBBkMRknnWJQ9Ywm7A3YMbAAbWT2vIJv1SAAuktLfGkIdE3h4Ax4YLusLXABREIocDkLNyquK5WmOD9woEYhitLN6UYjtzhOuKZzhVlNqHuO7Mpo-EglBg8gFHAwKYAIiG+if2CfFj0MCfSyYHJPM9zwAucdwYIA",
        children: "Playground example"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Here we use ", _jsx(_components.code, {
        children: "useTranslation"
      }), " from ", _jsx(_components.code, {
        children: "react-i18next"
      }), " and wrap the ", _jsx(_components.code, {
        children: "t"
      }), " translation function that is returned to override the type it gives us."]
    }), "\n", _jsx(_components.p, {
      children: "Now when engineers go to use the Button component, they will know they need a LocalizedString, and the most straightforward way to get it will be to use the i18next utilities that we also provide."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>When building web applications, enforcing that strings be localized to the user’s preferred language can sometimes be achieved via lint rules. But what if we could enforce proper localization using types in Typescript?</p>
<h2>Defining a Localized Type</h2>
<p>Typescript doesn’t natively provide an <a href="https://en.wikipedia.org/wiki/Opaque_data_type">Opaque type</a> that we can use to define a string that has already been localized. If the data looks like a string, Typescript will consider it a string. We can however use utility types that simulate opaque types, like the Opaque definition in <a href="https://github.com/sindresorhus/type-fest">type-fest</a>:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">import { Opaque } from &#x27;type-fest&#x27;;

type LocalizedString = Opaque&lt;&#x27;LocalizedString&#x27;, string&gt;;
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgeTAQwI4FcCmcC+cAZlBCHAOQwCeYOAtETgM4wUDcAUJzXXADIQAxmgA2wAF44AJgGUYUYADsA5nAC8KdNhwAeCoJHipchcpUUANHFaLVAPnZA">Playground example</a></p>
<p>Here is a short example where we create a localized string and try to use a raw string and our localized string in a function:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">import { Opaque } from &#x27;type-fest&#x27;;

type LocalizedString = Opaque&lt;&#x27;LocalizedString&#x27;, string&gt;;

function createLocalizedString(s: string): LocalizedString {
    return s as LocalizedString;
}

function example(s: LocalizedString) {
    return s;
}

console.log(example(&#x27;test&#x27;)); // Will throw a type error
console.log(example(createLocalizedString(&#x27;test&#x27;))); // Works correctly
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgeTAQwI4FcCmcC+cAZlBCHAOQwCeYOAtETgM4wUDcAUJzXXADIQAxmgA2wAF44AJgGUYUYADsA5nAC8KdNhwAeCoJHipchcpUUANHFaLVAPi6ciWJUJjAISuEKg40MDiGYpIy8nYqABTMAFw2ZqoAlHHBxmEJagiccDlwfjBYUN7McGglqaGmEVz43C5uHl5wOAAeaOCiONEpwiEm4eaJiNm5+YXFNdxCXswQnQB0ohBRre1gnZFULGyJiVzTSrMLSyttHV2+-oEV-RmbgawUu3tAA">Playground example</a></p>
<p>Now we have a type that we can use in our function and components to denote that we expect an already localized string to be used.</p>
<h2>Enforcing in Components</h2>
<p>The simplest way we can enforce that strings have already been localized is by using the type in our component’s props interface:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">
interface ButtonProps {
  label: LocalizedString;
}

function Button(props: ButtonProps) {
  return &lt;button&gt;{props.label}&lt;/button&gt;;
}
</code></pre></div>
<p>Now if we try to use that component without a localized string, we get an error:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">import React from &#x27;react&#x27;;
import { Opaque } from &#x27;type-fest&#x27;;

type LocalizedString = Opaque&lt;&#x27;LocalizedString&#x27;, string&gt;;

function createLocalizedString(s: string): LocalizedString {
    return s as LocalizedString;
}

interface ButtonProps {
  label: LocalizedString;
}

function Button(props: ButtonProps) {
  return &lt;button&gt;{props.label}&lt;/button&gt;;
}

function Example() {
    return (
        &lt;&gt;
            &lt;Button label=&quot;Test&quot; /&gt;
            &lt;Button label={createLocalizedString(&quot;Test&quot;)} /&gt;
        &lt;/&gt;
    );
}
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wG4AoUSWOAbzgHkwUBHAVyTgF85tcCYATzBIAtJiQBnGGXLkhIuABkIaFABtgALyQATAMowowAHYBzOAF5GzdkgA8+FWs06DR02fwAaONOPmAHwU5JhsJhjAECZwaEQoMEjOGtp6hgFmABSSAFx+HuYAlHnJrmkFFrTkcDVwRDBsUDGScCgtpanuGRRccqaJUJjonABCbDAw0QAKOGAtVTXqKABGSOolqilu6Z49cmERMFExYxPRmWCzuXCnkyYzEHOFdNV1SA1NcPbL43eBtJdHpIAHRLVbqLj2AD0PzOJmC5F6oXCkWicAAogAPFDgdRITLPBa1eqNGKZV61Wr2QIUyl0+y3NFgtaWABEABUpDBWXAoTS6QKvoyYsz1JZaHFUIkOtsKpkOVzWYUeHzaZTofzaoUekA">Playground example</a></p>
<h2>Localizing Strings</h2>
<p>So far, we’ve been using a utility <code>createLocalizedString</code> to create and use the LocalizedString type. This utility is only really practical in unit tests. For real applications, we’ll want to use a translation function from <a href="https://github.com/i18next/react-i18next">react-i18next</a> or <a href="https://github.com/i18next/next-i18next">next-i18next</a> to do the heavy lifting. Then we just wrap the translation functions that are provided in order to use our type:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">import React, { useCallback } from &#x27;react&#x27;;
import { Opaque } from &#x27;type-fest&#x27;;
import { useTranslation } from &#x27;react-i18next&#x27;;

type LocalizedString = Opaque&lt;&#x27;LocalizedString&#x27;, string&gt;;

function createLocalizedString(s: string): LocalizedString {
    return s as LocalizedString;
}

interface ButtonProps {
  label: LocalizedString;
}

function Button(props: ButtonProps) {
  return &lt;button&gt;{props.label}&lt;/button&gt;;
}

function useLocalizedTranslation() {
    const { t : originalTranslate } = useTranslation();

    const t = useCallback((key: string, defaultString: string) =&gt; {
        return originalTranslate(key, defaultString) as LocalizedString;
    }, [originalTranslate]);

    return { t };
}

function Example() {
    const { t } = useLocalizedTranslation();
    return (
        &lt;&gt;
            &lt;Button label={t(&quot;test&quot;, &quot;Test&quot;)} /&gt;
        &lt;/&gt;
    );
}
</code></pre></div>
<p><a href="https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDGMA0cDecCuAzkgMIoA25ARugNZwC+cAZlBCHAORSoacDcAKFCRYuOAHkwKAI74kjFmw6cYATzBIAtMySEYA4eGjw8RJABUoKAHaFyKGMAg3Frdlx7oYW4AEYADhskAA8DIUF1TTgAGQg0CmAALyQAEwBlGChgGwBzOABeSWk5JAAeTjiE8mS0zOy8zmx9BtyAPgjmfBsMZ1c0LxgkKsSUjKyc3IAKQgAuOBbJgEp5kZqx+sncQThduB4YfChXQjgUU7Xa8dahBkFhGyGoZnQFACF8GBgXAAU2MFOOB2cAcVCQ5FW8VGdQmeVu9y6PScLjgHy+LimYH+c1Rn2+Nj+EABS22uwOR1cZSoeJcbRwWKJhAAdKDwQwygB6anomwdQR3QSI3oo8yXMZWWz2Rx9KYkoF7OBoFz6cTwebQYC5HIUCV2BxDRRFcy6qXImyyiIKpV2eDwI3EMiUGhoWhTKa0JBqeaLPLYVJIF74cgwTZ5b2w3IkgptUkKvbk45wDVamw66x6xxId2ev0BlBBkMRknnWJQ9Ywm7A3YMbAAbWT2vIJv1SAAuktLfGkIdE3h4Ax4YLusLXABREIocDkLNyquK5WmOD9woEYhitLN6UYjtzhOuKZzhVlNqHuO7Mpo-EglBg8gFHAwKYAIiG+if2CfFj0MCfSyYHJPM9zwAucdwYIA">Playground example</a></p>
<p>Here we use <code>useTranslation</code> from <code>react-i18next</code> and wrap the <code>t</code> translation function that is returned to override the type it gives us.</p>
<p>Now when engineers go to use the Button component, they will know they need a LocalizedString, and the most straightforward way to get it will be to use the i18next utilities that we also provide.</p>


When building web applications, enforcing that strings be localized to the user’s preferred language can sometimes be achieved via lint rules. But what if we could enforce proper localization using types in Typescript?

## Defining a Localized Type

Typescript doesn’t natively provide an [Opaque type](https://en.wikipedia.org/wiki/Opaque_data_type) that we can use to define a string that has already been localized. If the data looks like a string, Typescript will consider it a string. We can however use utility types that simulate opaque types, like the Opaque definition in [type-fest](https://github.com/sindresorhus/type-fest):

```tsx
import { Opaque } from 'type-fest';

type LocalizedString = Opaque<'LocalizedString', string>;
```

[Playground example](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgeTAQwI4FcCmcC+cAZlBCHAOQwCeYOAtETgM4wUDcAUJzXXADIQAxmgA2wAF44AJgGUYUYADsA5nAC8KdNhwAeCoJHipchcpUUANHFaLVAPnZA)

Here is a short example where we create a localized string and try to use a raw string and our localized string in a function:

```tsx
import { Opaque } from 'type-fest';

type LocalizedString = Opaque<'LocalizedString', string>;

function createLocalizedString(s: string): LocalizedString {
    return s as LocalizedString;
}

function example(s: LocalizedString) {
    return s;
}

console.log(example('test')); // Will throw a type error
console.log(example(createLocalizedString('test'))); // Works correctly
```

[Playground example](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgeTAQwI4FcCmcC+cAZlBCHAOQwCeYOAtETgM4wUDcAUJzXXADIQAxmgA2wAF44AJgGUYUYADsA5nAC8KdNhwAeCoJHipchcpUUANHFaLVAPi6ciWJUJjAISuEKg40MDiGYpIy8nYqABTMAFw2ZqoAlHHBxmEJagiccDlwfjBYUN7McGglqaGmEVz43C5uHl5wOAAeaOCiONEpwiEm4eaJiNm5+YXFNdxCXswQnQB0ohBRre1gnZFULGyJiVzTSrMLSyttHV2+-oEV-RmbgawUu3tAA)

Now we have a type that we can use in our function and components to denote that we expect an already localized string to be used.

## Enforcing in Components

The simplest way we can enforce that strings have already been localized is by using the type in our component’s props interface:

```tsx

interface ButtonProps {
  label: LocalizedString;
}

function Button(props: ButtonProps) {
  return <button>{props.label}</button>;
}
```

Now if we try to use that component without a localized string, we get an error:

```tsx
import React from 'react';
import { Opaque } from 'type-fest';

type LocalizedString = Opaque<'LocalizedString', string>;

function createLocalizedString(s: string): LocalizedString {
    return s as LocalizedString;
}

interface ButtonProps {
  label: LocalizedString;
}

function Button(props: ButtonProps) {
  return <button>{props.label}</button>;
}

function Example() {
    return (
        <>
            <Button label="Test" />
            <Button label={createLocalizedString("Test")} />
        </>
    );
}
```

[Playground example](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wG4AoUSWOAbzgHkwUBHAVyTgF85tcCYATzBIAtJiQBnGGXLkhIuABkIaFABtgALyQATAMowowAHYBzOAF5GzdkgA8+FWs06DR02fwAaONOPmAHwU5JhsJhjAECZwaEQoMEjOGtp6hgFmABSSAFx+HuYAlHnJrmkFFrTkcDVwRDBsUDGScCgtpanuGRRccqaJUJjonABCbDAw0QAKOGAtVTXqKABGSOolqilu6Z49cmERMFExYxPRmWCzuXCnkyYzEHOFdNV1SA1NcPbL43eBtJdHpIAHRLVbqLj2AD0PzOJmC5F6oXCkWicAAogAPFDgdRITLPBa1eqNGKZV61Wr2QIUyl0+y3NFgtaWABEABUpDBWXAoTS6QKvoyYsz1JZaHFUIkOtsKpkOVzWYUeHzaZTofzaoUekA)

## Localizing Strings

So far, we’ve been using a utility `createLocalizedString` to create and use the LocalizedString type. This utility is only really practical in unit tests. For real applications, we’ll want to use a translation function from [react-i18next](https://github.com/i18next/react-i18next) or [next-i18next](https://github.com/i18next/next-i18next) to do the heavy lifting. Then we just wrap the translation functions that are provided in order to use our type:

```tsx
import React, { useCallback } from 'react';
import { Opaque } from 'type-fest';
import { useTranslation } from 'react-i18next';

type LocalizedString = Opaque<'LocalizedString', string>;

function createLocalizedString(s: string): LocalizedString {
    return s as LocalizedString;
}

interface ButtonProps {
  label: LocalizedString;
}

function Button(props: ButtonProps) {
  return <button>{props.label}</button>;
}

function useLocalizedTranslation() {
    const { t : originalTranslate } = useTranslation();

    const t = useCallback((key: string, defaultString: string) => {
        return originalTranslate(key, defaultString) as LocalizedString;
    }, [originalTranslate]);

    return { t };
}

function Example() {
    const { t } = useLocalizedTranslation();
    return (
        <>
            <Button label={t("test", "Test")} />
        </>
    );
}
```

[Playground example](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDGMA0cDecCuAzkgMIoA25ARugNZwC+cAZlBCHAORSoacDcAKFCRYuOAHkwKAI74kjFmw6cYATzBIAtMySEYA4eGjw8RJABUoKAHaFyKGMAg3Frdlx7oYW4AEYADhskAA8DIUF1TTgAGQg0CmAALyQAEwBlGChgGwBzOABeSWk5JAAeTjiE8mS0zOy8zmx9BtyAPgjmfBsMZ1c0LxgkKsSUjKyc3IAKQgAuOBbJgEp5kZqx+sncQThduB4YfChXQjgUU7Xa8dahBkFhGyGoZnQFACF8GBgXAAU2MFOOB2cAcVCQ5FW8VGdQmeVu9y6PScLjgHy+LimYH+c1Rn2+Nj+EABS22uwOR1cZSoeJcbRwWKJhAAdKDwQwygB6anomwdQR3QSI3oo8yXMZWWz2Rx9KYkoF7OBoFz6cTwebQYC5HIUCV2BxDRRFcy6qXImyyiIKpV2eDwI3EMiUGhoWhTKa0JBqeaLPLYVJIF74cgwTZ5b2w3IkgptUkKvbk45wDVamw66x6xxId2ev0BlBBkMRknnWJQ9Ywm7A3YMbAAbWT2vIJv1SAAuktLfGkIdE3h4Ax4YLusLXABREIocDkLNyquK5WmOD9woEYhitLN6UYjtzhOuKZzhVlNqHuO7Mpo-EglBg8gFHAwKYAIiG+if2CfFj0MCfSyYHJPM9zwAucdwYIA)

Here we use `useTranslation` from `react-i18next` and wrap the `t` translation function that is returned to override the type it gives us.

Now when engineers go to use the Button component, they will know they need a LocalizedString, and the most straightforward way to get it will be to use the i18next utilities that we also provide.


Enforcing Localization through Types

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code",
    h2: "h2",
    pre: "pre",
    strong: "strong"
  }, props.components), {Mermaid} = _components;
  if (!Mermaid) _missingMdxReference("Mermaid", true);
  return _jsxs(_Fragment, {
    children: [_jsxs(_components.p, {
      children: ["A common pattern in larger application when trying to track feature usage is to try to namespace events. For example, you might have a button that you want to track clicks on. For the sake of this article, we will use the ", _jsx(_components.code, {
        children: "data-track"
      }), " attribute on elements to track their usage, but you can imagine this works with any tracking implementation where you may need to explicitly call a tracking function (e.g. ", _jsx(_components.code, {
        children: "track(namespace)"
      }), ")."]
    }), "\n", _jsx(_components.h2, {
      children: "Simple Example"
    }), "\n", _jsx(_components.p, {
      children: "As requests to start tracking user events come up, typically the easiest way is to just hard code the tracking namespaces:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "<button data-track=\"chat.form.send\">Send<button>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "And as the tracking grows, these might get moved to a separate file and a constant/enumeration:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "const ChatTracking = {\n  send: 'chat.form.send',\n  attachMedia: 'chat.form.attachMedia',\n  edit: 'chat.messages.edit',\n  delete: 'chat.messages.delete',\n} as const;\n\n// usage\n\n<button data-track={ChatTracking.send}>Send</button>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "We have a lot of string duplication here. We might be tempted to use template strings or some other way of creating the string, but it doesn’t end up reducing any of the duplication."
    }), "\n", _jsx(_components.h2, {
      children: "Passing Namespaces"
    }), "\n", _jsx(_components.p, {
      children: "As the application grows more complex, an engineer working on another set of features ends up wanting to re-use the chat form from above. It already has some additional animation and composes together the component library widgets, why not re-use it in the context of forums."
    }), "\n", _jsxs(_components.p, {
      children: ["Except now the ", _jsx(_components.code, {
        children: "data-track"
      }), " attribute has to be passed in as a prop:"]
    }), "\n", _jsx(Mermaid, {
      chart: "graph TD\n  Forums --> ChatForm\n  Chat --> ChatForm\n  ChatForm --> SendButton\n  SendButton --> Button\n"
    }), "\n", _jsx(_components.p, {
      children: "The Forums usage ends up adding its own tracking attribute, but ends up having to prop-drill down the namespace from the Forums components, through the ChatForm, to the SendButton component."
    }), "\n", _jsx(_components.h2, {
      children: "Using Context"
    }), "\n", _jsx(_components.p, {
      children: "Instead, what if we wrap our features in some Context component that helps us track where our components are being used. Then we can just build up the tracking namespace based on where the component is in the feature tree, rather than having to keep track of long namespace strings."
    }), "\n", _jsx(_components.p, {
      children: "First let’s build a context in React:"
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.strong, {
        children: "FeatureContext.tsx"
      })
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "import { createContext } from 'react';\n\n/**\n * Context for tracking features\n */\nexport const FeatureContext = createContext<string[]>([]);\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Then we’ll create a helper component that we can use throughout the application:"
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.strong, {
        children: "Feature.tsx"
      })
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "import type { ReactNode } from 'react';\nimport { useContext, useMemo } from 'react';\nimport { FeatureContext } from './FeatureContext';\n\nexport interface FeatureProps {\n    readonly name: string;\n    readonly children: ReactNode;\n    readonly topLevel?: boolean;\n}\n\nexport function Feature({\n    name,\n    children,\n    topLevel,\n}: FeatureProps): JSX.Element {\n    const parentContext = useContext(FeatureContext);\n\n    const currentContext = useMemo(() => {\n        if (topLevel === true) {\n            return [name];\n        }\n        return [...parentContext, name];\n    }, [parentContext, name, topLevel]);\n\n    return (\n        <FeatureContext.Provider value={currentContext}>\n            {children}\n        </FeatureContext.Provider>\n    );\n}\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Usage of this component would look like:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function Forums() {\n  return (\n    <Feature name=\"forums\">\n      <ChatForm />\n    </Feature>\n  );\n}\n\nfunction Chat() {\n  return (\n    <Feature name=\"chat\">\n      <ChatForm />\n    </Feature>\n  );\n}\n\nfunction ChatForm() {\n  return (\n    <Feature name=\"form\">\n      <SendButton />\n    </Feature>\n  );\n}\n\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Then, in SendButton, when we actually need to use the feature context, we construct the namespace:"
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.strong, {
        children: "SendButton.tsx"
      })
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "function SendButton() {\n  const featureContext = useContext(FeatureContext);\n\n  return (\n    <button data-track={[...featureContext, 'send'].join('.')}>Send</button>\n  );\n}\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Note: the above example has been simplified for this article’s sake. Typically some utility for reading the context, joining the namespaces, and memoizing the value would be provided."
    }), "\n", _jsx(_components.p, {
      children: "No additional props are needed, and the Feature components can be used throughout the application as a standard mechanism for building up feature namespaces."
    }), "\n", _jsx(_components.h2, {
      children: "Conclusion"
    }), "\n", _jsx(_components.p, {
      children: "Rather than trying to alleviate string duplication and prop-drilling as separate problems, we can leverage React Context to solve both problems at the same time and leverage context to determine where we are in a feature tree. Not only does the Feature context help with constructing the data-track attributes, but it now provides a consistent mechanism that we can use throughout the application to let components know the feature namespace they are currently in without the parent components prop-drilling the namespace down to every component."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};
function _missingMdxReference(id, component) {
  throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it.");
}


<p>A common pattern in larger application when trying to track feature usage is to try to namespace events. For example, you might have a button that you want to track clicks on. For the sake of this article, we will use the <code>data-track</code> attribute on elements to track their usage, but you can imagine this works with any tracking implementation where you may need to explicitly call a tracking function (e.g. <code>track(namespace)</code>).</p>
<h2>Simple Example</h2>
<p>As requests to start tracking user events come up, typically the easiest way is to just hard code the tracking namespaces:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">&lt;button data-track=&quot;chat.form.send&quot;&gt;Send&lt;button&gt;
</code></pre></div>
<p>And as the tracking grows, these might get moved to a separate file and a constant/enumeration:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">const ChatTracking = {
  send: &#x27;chat.form.send&#x27;,
  attachMedia: &#x27;chat.form.attachMedia&#x27;,
  edit: &#x27;chat.messages.edit&#x27;,
  delete: &#x27;chat.messages.delete&#x27;,
} as const;

// usage

&lt;button data-track={ChatTracking.send}&gt;Send&lt;/button&gt;
</code></pre></div>
<p>We have a lot of string duplication here. We might be tempted to use template strings or some other way of creating the string, but it doesn’t end up reducing any of the duplication.</p>
<h2>Passing Namespaces</h2>
<p>As the application grows more complex, an engineer working on another set of features ends up wanting to re-use the chat form from above. It already has some additional animation and composes together the component library widgets, why not re-use it in the context of forums.</p>
<p>Except now the <code>data-track</code> attribute has to be passed in as a prop:</p>
<div class="py-8 [&amp;_svg]:m-auto"><div class="mermaid" data-mermaid-src="graph TD
  Forums --&gt; ChatForm
  Chat --&gt; ChatForm
  ChatForm --&gt; SendButton
  SendButton --&gt; Button
">graph TD
  Forums --&gt; ChatForm
  Chat --&gt; ChatForm
  ChatForm --&gt; SendButton
  SendButton --&gt; Button
</div></div>
<p>The Forums usage ends up adding its own tracking attribute, but ends up having to prop-drill down the namespace from the Forums components, through the ChatForm, to the SendButton component.</p>
<h2>Using Context</h2>
<p>Instead, what if we wrap our features in some Context component that helps us track where our components are being used. Then we can just build up the tracking namespace based on where the component is in the feature tree, rather than having to keep track of long namespace strings.</p>
<p>First let’s build a context in React:</p>
<p><strong>FeatureContext.tsx</strong></p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">import { createContext } from &#x27;react&#x27;;

/**
 * Context for tracking features
 */
export const FeatureContext = createContext&lt;string[]&gt;([]);
</code></pre></div>
<p>Then we’ll create a helper component that we can use throughout the application:</p>
<p><strong>Feature.tsx</strong></p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">import type { ReactNode } from &#x27;react&#x27;;
import { useContext, useMemo } from &#x27;react&#x27;;
import { FeatureContext } from &#x27;./FeatureContext&#x27;;

export interface FeatureProps {
    readonly name: string;
    readonly children: ReactNode;
    readonly topLevel?: boolean;
}

export function Feature({
    name,
    children,
    topLevel,
}: FeatureProps): JSX.Element {
    const parentContext = useContext(FeatureContext);

    const currentContext = useMemo(() =&gt; {
        if (topLevel === true) {
            return [name];
        }
        return [...parentContext, name];
    }, [parentContext, name, topLevel]);

    return (
        &lt;FeatureContext.Provider value={currentContext}&gt;
            {children}
        &lt;/FeatureContext.Provider&gt;
    );
}
</code></pre></div>
<p>Usage of this component would look like:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">function Forums() {
  return (
    &lt;Feature name=&quot;forums&quot;&gt;
      &lt;ChatForm /&gt;
    &lt;/Feature&gt;
  );
}

function Chat() {
  return (
    &lt;Feature name=&quot;chat&quot;&gt;
      &lt;ChatForm /&gt;
    &lt;/Feature&gt;
  );
}

function ChatForm() {
  return (
    &lt;Feature name=&quot;form&quot;&gt;
      &lt;SendButton /&gt;
    &lt;/Feature&gt;
  );
}

</code></pre></div>
<p>Then, in SendButton, when we actually need to use the feature context, we construct the namespace:</p>
<p><strong>SendButton.tsx</strong></p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">function SendButton() {
  const featureContext = useContext(FeatureContext);

  return (
    &lt;button data-track={[...featureContext, &#x27;send&#x27;].join(&#x27;.&#x27;)}&gt;Send&lt;/button&gt;
  );
}
</code></pre></div>
<p>Note: the above example has been simplified for this article’s sake. Typically some utility for reading the context, joining the namespaces, and memoizing the value would be provided.</p>
<p>No additional props are needed, and the Feature components can be used throughout the application as a standard mechanism for building up feature namespaces.</p>
<h2>Conclusion</h2>
<p>Rather than trying to alleviate string duplication and prop-drilling as separate problems, we can leverage React Context to solve both problems at the same time and leverage context to determine where we are in a feature tree. Not only does the Feature context help with constructing the data-track attributes, but it now provides a consistent mechanism that we can use throughout the application to let components know the feature namespace they are currently in without the parent components prop-drilling the namespace down to every component.</p>


A common pattern in larger application when trying to track feature usage is to try to namespace events. For example, you might have a button that you want to track clicks on. For the sake of this article, we will use the `data-track` attribute on elements to track their usage, but you can imagine this works with any tracking implementation where you may need to explicitly call a tracking function (e.g. `track(namespace)`).

## Simple Example

As requests to start tracking user events come up, typically the easiest way is to just hard code the tracking namespaces:

```tsx
<button data-track="chat.form.send">Send<button>
```

And as the tracking grows, these might get moved to a separate file and a constant/enumeration:

```tsx
const ChatTracking = {
  send: 'chat.form.send',
  attachMedia: 'chat.form.attachMedia',
  edit: 'chat.messages.edit',
  delete: 'chat.messages.delete',
} as const;

// usage

<button data-track={ChatTracking.send}>Send</button>
```

We have a lot of string duplication here. We might be tempted to use template strings or some other way of creating the string, but it doesn’t end up reducing any of the duplication.

## Passing Namespaces

As the application grows more complex, an engineer working on another set of features ends up wanting to re-use the chat form from above. It already has some additional animation and composes together the component library widgets, why not re-use it in the context of forums.

Except now the `data-track` attribute has to be passed in as a prop:

```mermaid
graph TD
  Forums --> ChatForm
  Chat --> ChatForm
  ChatForm --> SendButton
  SendButton --> Button

```

The Forums usage ends up adding its own tracking attribute, but ends up having to prop-drill down the namespace from the Forums components, through the ChatForm, to the SendButton component.

## Using Context

Instead, what if we wrap our features in some Context component that helps us track where our components are being used. Then we can just build up the tracking namespace based on where the component is in the feature tree, rather than having to keep track of long namespace strings.

First let’s build a context in React:

**FeatureContext.tsx**

```tsx
import { createContext } from 'react';

/**
 * Context for tracking features
 */
export const FeatureContext = createContext<string[]>([]);
```

Then we’ll create a helper component that we can use throughout the application:

**Feature.tsx**

```tsx
import type { ReactNode } from 'react';
import { useContext, useMemo } from 'react';
import { FeatureContext } from './FeatureContext';

export interface FeatureProps {
    readonly name: string;
    readonly children: ReactNode;
    readonly topLevel?: boolean;
}

export function Feature({
    name,
    children,
    topLevel,
}: FeatureProps): JSX.Element {
    const parentContext = useContext(FeatureContext);

    const currentContext = useMemo(() => {
        if (topLevel === true) {
            return [name];
        }
        return [...parentContext, name];
    }, [parentContext, name, topLevel]);

    return (
        <FeatureContext.Provider value={currentContext}>
            {children}
        </FeatureContext.Provider>
    );
}
```

Usage of this component would look like:

```tsx
function Forums() {
  return (
    <Feature name="forums">
      <ChatForm />
    </Feature>
  );
}

function Chat() {
  return (
    <Feature name="chat">
      <ChatForm />
    </Feature>
  );
}

function ChatForm() {
  return (
    <Feature name="form">
      <SendButton />
    </Feature>
  );
}

```

Then, in SendButton, when we actually need to use the feature context, we construct the namespace:

**SendButton.tsx**

```tsx
function SendButton() {
  const featureContext = useContext(FeatureContext);

  return (
    <button data-track={[...featureContext, 'send'].join('.')}>Send</button>
  );
}
```

Note: the above example has been simplified for this article’s sake. Typically some utility for reading the context, joining the namespaces, and memoizing the value would be provided.

No additional props are needed, and the Feature components can be used throughout the application as a standard mechanism for building up feature namespaces.

## Conclusion

Rather than trying to alleviate string duplication and prop-drilling as separate problems, we can leverage React Context to solve both problems at the same time and leverage context to determine where we are in a feature tree. Not only does the Feature context help with constructing the data-track attributes, but it now provides a consistent mechanism that we can use throughout the application to let components know the feature namespace they are currently in without the parent components prop-drilling the namespace down to every component.


Feature Contexts

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    pre: "pre",
    code: "code",
    a: "a",
    strong: "strong",
    h2: "h2"
  }, 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, Object.assign({}, 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    pre: "pre",
    code: "code",
    a: "a",
    h2: "h2"
  }, 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, Object.assign({}, 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code",
    pre: "pre",
    a: "a",
    h2: "h2"
  }, 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, Object.assign({}, 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    a: "a",
    strong: "strong",
    code: "code",
    pre: "pre",
    h2: "h2"
  }, 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, Object.assign({}, 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code",
    pre: "pre",
    a: "a",
    em: "em",
    h2: "h2",
    blockquote: "blockquote"
  }, 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, Object.assign({}, 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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 bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 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

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code",
    pre: "pre"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsxs(_components.p, {
      children: ["I was working on a project and I noticed the ", _jsx(_components.code, {
        children: "tsc"
      }), " check that we ran on pre-commit hooks had become dramatically slower. I was seeing near instant times to type check the entire project go to agonizingly slow minutes to check the project. I was able to narrow the range of commits to some change we made within a month window. I’m sure I could have narrowed it down by continuing to git bisect and re-running ", _jsx(_components.code, {
        children: "time npx tsc"
      }), ", but it was much easier to just check out main and try out the following:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-bash",
        children: "# remove any pre-built definitions to get a good baseline\nrm -r .tsBuildInfo\n\n# Get some baseline stats\ntime npx tsc\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "I was seeing values around (times have been modified for blogging purposes):"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-bash",
        children: "real 1m30.000s\nuser 2m0.000s\nsys 0m3.000s\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["After running the baseline trace, I could analyze the ", _jsx(_components.code, {
        children: "tsc"
      }), " trace and use a nifty tool called ", _jsx(_components.code, {
        children: "analyze-trace"
      }), " that will report hotspots:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-bash",
        children: "npm i -g @typescript/analyze-trace\n\nnpx tsc --generateTrace ./.trace\nnpx analyze-trace ./.trace\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "This command will spit out which files are hotspots in your codebase. To my surprise, I was seeing build outputs from webpack as a hotspot."
    }), "\n", _jsxs(_components.p, {
      children: ["Turns out the ", _jsx(_components.code, {
        children: "tsconfig.json"
      }), " had been slightly modified and accidentally included the build folder. Adding the build folder to the excludes entry sped up the tsc command by quite a bit:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-bash",
        children: "real 0m30.000s\nuser 0m47.000s\nsys 0m2.000s\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Not only did the trace help me identify the major hotspot in the code, but also\nindicated some additional areas that I could improve upon going forward."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>I was working on a project and I noticed the <code>tsc</code> check that we ran on pre-commit hooks had become dramatically slower. I was seeing near instant times to type check the entire project go to agonizingly slow minutes to check the project. I was able to narrow the range of commits to some change we made within a month window. I’m sure I could have narrowed it down by continuing to git bisect and re-running <code>time npx tsc</code>, but it was much easier to just check out main and try out the following:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-bash"># remove any pre-built definitions to get a good baseline
rm -r .tsBuildInfo

# Get some baseline stats
time npx tsc
</code></pre></div>
<p>I was seeing values around (times have been modified for blogging purposes):</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-bash">real 1m30.000s
user 2m0.000s
sys 0m3.000s
</code></pre></div>
<p>After running the baseline trace, I could analyze the <code>tsc</code> trace and use a nifty tool called <code>analyze-trace</code> that will report hotspots:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-bash">npm i -g @typescript/analyze-trace

npx tsc --generateTrace ./.trace
npx analyze-trace ./.trace
</code></pre></div>
<p>This command will spit out which files are hotspots in your codebase. To my surprise, I was seeing build outputs from webpack as a hotspot.</p>
<p>Turns out the <code>tsconfig.json</code> had been slightly modified and accidentally included the build folder. Adding the build folder to the excludes entry sped up the tsc command by quite a bit:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-bash">real 0m30.000s
user 0m47.000s
sys 0m2.000s
</code></pre></div>
<p>Not only did the trace help me identify the major hotspot in the code, but also
indicated some additional areas that I could improve upon going forward.</p>


I was working on a project and I noticed the `tsc` check that we ran on pre-commit hooks had become dramatically slower. I was seeing near instant times to type check the entire project go to agonizingly slow minutes to check the project. I was able to narrow the range of commits to some change we made within a month window. I’m sure I could have narrowed it down by continuing to git bisect and re-running `time npx tsc`, but it was much easier to just check out main and try out the following:

```bash
# remove any pre-built definitions to get a good baseline
rm -r .tsBuildInfo

# Get some baseline stats
time npx tsc
```

I was seeing values around (times have been modified for blogging purposes):

```bash
real 1m30.000s
user 2m0.000s
sys 0m3.000s
```

After running the baseline trace, I could analyze the `tsc` trace and use a nifty tool called `analyze-trace` that will report hotspots:

```bash
npm i -g @typescript/analyze-trace

npx tsc --generateTrace ./.trace
npx analyze-trace ./.trace
```

This command will spit out which files are hotspots in your codebase. To my surprise, I was seeing build outputs from webpack as a hotspot.

Turns out the `tsconfig.json` had been slightly modified and accidentally included the build folder. Adding the build folder to the excludes entry sped up the tsc command by quite a bit:

```bash
real 0m30.000s
user 0m47.000s
sys 0m2.000s
```

Not only did the trace help me identify the major hotspot in the code, but also
indicated some additional areas that I could improve upon going forward.


Debugging slow tsc

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    a: "a",
    h2: "h2",
    ul: "ul",
    li: "li"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "To kickstart the year, I created a repo that contains a simple starter kit for using NextJS with NX. You can see the repo here:"
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.a, {
        href: "https://github.com/idmontie/nx-nextjs-starter",
        children: "Github"
      })
    }), "\n", _jsx(_components.p, {
      children: "This personal Github page is built using this starter kit. I wanted to create a starter kit that was simple and easy to use and also has a lot of eslint and Typescript configuration setup. I've also been working on revamping the website for Dark Emblem - my NFT side-project. The starter kit is based on the linting rules and Typescript set up that I've been using for that project."
    }), "\n", _jsx(_components.h2, {
      children: "Nx"
    }), "\n", _jsx(_components.p, {
      children: "I've traditionally used Lerna for my monorepo projects, but now that Nx has taken over maintenance of Lerna, I decided to give Nx a try directly."
    }), "\n", _jsx(_components.p, {
      children: "Nx has been enjoyable to use. Managing many different React projects with internal libraries has been very easy to set up, use and deploy."
    }), "\n", _jsx(_components.h2, {
      children: "NextJS"
    }), "\n", _jsx(_components.p, {
      children: "My last few projects have been Single Page Apps (SPAs) or statically generated sites using Gatsby or Docusaurus. All three of those tools are great, but I wanted to try out NextJS for a few reasons:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "In my Dark Emblem project, I was having difficulty getting share links to Discord and Twitter to work properly. This was mainly caused by those sites not running JavaScript, so page links would just render the default SPA title and description. I knew that NextJS had a solution for this, so I wanted to try it out."
      }), "\n", _jsx(_components.li, {
        children: "I wanted more control of my documentation and blog websites, so I needed to be able to use custom server-side code."
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "Starter Kit"
    }), "\n", _jsx(_components.p, {
      children: "Overall the starter kit is a pretty simple example. It just containers preconfigured Nx, husky, lint-staged, eslint, prettier, Typescript, and NextJS. It does not contain any UI components or anything like that. It's just a simple starter kit to get you up and running with a monorepo NextJS project."
    }), "\n", _jsxs(_components.p, {
      children: ["Feel free to check it out at ", _jsx(_components.a, {
        href: "https://github.com/idmontie/nx-nextjs-starter",
        children: "Github"
      }), "."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>To kickstart the year, I created a repo that contains a simple starter kit for using NextJS with NX. You can see the repo here:</p>
<p><a href="https://github.com/idmontie/nx-nextjs-starter">Github</a></p>
<p>This personal Github page is built using this starter kit. I wanted to create a starter kit that was simple and easy to use and also has a lot of eslint and Typescript configuration setup. I&#x27;ve also been working on revamping the website for Dark Emblem - my NFT side-project. The starter kit is based on the linting rules and Typescript set up that I&#x27;ve been using for that project.</p>
<h2>Nx</h2>
<p>I&#x27;ve traditionally used Lerna for my monorepo projects, but now that Nx has taken over maintenance of Lerna, I decided to give Nx a try directly.</p>
<p>Nx has been enjoyable to use. Managing many different React projects with internal libraries has been very easy to set up, use and deploy.</p>
<h2>NextJS</h2>
<p>My last few projects have been Single Page Apps (SPAs) or statically generated sites using Gatsby or Docusaurus. All three of those tools are great, but I wanted to try out NextJS for a few reasons:</p>
<ul>
<li>In my Dark Emblem project, I was having difficulty getting share links to Discord and Twitter to work properly. This was mainly caused by those sites not running JavaScript, so page links would just render the default SPA title and description. I knew that NextJS had a solution for this, so I wanted to try it out.</li>
<li>I wanted more control of my documentation and blog websites, so I needed to be able to use custom server-side code.</li>
</ul>
<h2>Starter Kit</h2>
<p>Overall the starter kit is a pretty simple example. It just containers preconfigured Nx, husky, lint-staged, eslint, prettier, Typescript, and NextJS. It does not contain any UI components or anything like that. It&#x27;s just a simple starter kit to get you up and running with a monorepo NextJS project.</p>
<p>Feel free to check it out at <a href="https://github.com/idmontie/nx-nextjs-starter">Github</a>.</p>


To kickstart the year, I created a repo that contains a simple starter kit for using NextJS with NX. You can see the repo here:

[Github](https://github.com/idmontie/nx-nextjs-starter)

This personal Github page is built using this starter kit. I wanted to create a starter kit that was simple and easy to use and also has a lot of eslint and Typescript configuration setup. I've also been working on revamping the website for Dark Emblem - my NFT side-project. The starter kit is based on the linting rules and Typescript set up that I've been using for that project.

## Nx

I've traditionally used Lerna for my monorepo projects, but now that Nx has taken over maintenance of Lerna, I decided to give Nx a try directly.

Nx has been enjoyable to use. Managing many different React projects with internal libraries has been very easy to set up, use and deploy.

## NextJS

My last few projects have been Single Page Apps (SPAs) or statically generated sites using Gatsby or Docusaurus. All three of those tools are great, but I wanted to try out NextJS for a few reasons:

* In my Dark Emblem project, I was having difficulty getting share links to Discord and Twitter to work properly. This was mainly caused by those sites not running JavaScript, so page links would just render the default SPA title and description. I knew that NextJS had a solution for this, so I wanted to try it out.
* I wanted more control of my documentation and blog websites, so I needed to be able to use custom server-side code.

## Starter Kit

Overall the starter kit is a pretty simple example. It just containers preconfigured Nx, husky, lint-staged, eslint, prettier, Typescript, and NextJS. It does not contain any UI components or anything like that. It's just a simple starter kit to get you up and running with a monorepo NextJS project.

Feel free to check it out at [Github](https://github.com/idmontie/nx-nextjs-starter).