react 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.


Enforcing Localization through Types

Feature Contexts