DEV Community: Kapelianovych Yevhen

Implementing a grid system using a simple hand-written single-pass compiler in Sass

Kapelianovych Yevhen — Sun, 16 Jan 2022 09:12:46 +0000

What’s the first thing that pops up in your mind when you think about Sass? Yes, it is the powerful CSS preprocessor that is widely used now. You may also say that it has convenient features for encapsulating repeated parts of the CSS or some complex cases. You might mention nesting, placeholders, etc. But Sass is more powerful than that because it has SassScript.

So, what is this?

SassScript is a set of extensions that can be included in the Sass documents to compute variables from property values and uses properties of variables, arithmetic, and other functions. That gives us the ability to organize a code into functions, perform conditional operations, and many more. Actually, these two abilities are enough to build a whole program.

So, let’s start.

Typical parser implementations theory defines using a character reader, which is used by a lexer that produces tokens, and the last one is the parser itself which creates the AST.

We will build a less capable compiler because Sass has some limitations. Sass cannot work with a filesystem in any way. Because of that, we cannot store custom syntax in separate files. So we should write it inside Sass files. Also, it is inconvenient to process a character's stream because Sass does not provide the most valuable methods for working with strings (and it does not have streams at all). The same goes for the lexer. But we can simulate the latter if we assume that all keywords are already tokens. Sass has a list structure where a space can be a separator between items. And there is a sass:list module that provides some functions to work with lists. We are going to use that ability to simulate the lexer skipping the character sequence stream at all. All the code we are going to write as an argument to a value function. And despite the length of the words, it will still be the list!

value(sequence of the tokens);

Let me describe the idea.

We plan to create a simple responsive grid system. For that, we will assume that there is a table with 64 columns (there may be more or less, it depends) which covers a whole page. Each cell of the table is a square figure. It gives us responsiveness because, on mobile phones, cells will have a smaller size than on laptops. Based on that, we receive a dynamic value (one side of the cell) that we use to express all dimensions in our grid.

You may want to use rem or vw for that purpose. And that’s okay. It’s up to you how to define a unit value.
With that, we’ll be able to say, for example, that “this block should have a width of 5 columns“, and blocks will resize according to unit value changes.

Okay, let’s jump into the code now.

The simplest thing is to calculate the unit value. We know that the grid will have 64 columns. So, the width of one cell can be defined like this:

@use 'sass:math';

:root {
  -—unit: math.div(100vw, 64);
}

Later, I won’t write imports of standard Sass’s modules for brevity. Assume that they are present already.

We took a benefit from CSS variables here and made it global. That will allow us to access this value everywhere in the runtime. We can place it into the mixin named init to allow the developer to override the columns count.

@mixin init($columns: 64) {
  :root {
    —-unit: math.div(100vw, #{$columns});
  }
}

Also, you can define lower and upper bounds for the unit value by using clamp CSS function, but we won’t do that to simplify the code examples.

Move on to the syntax. We're expecting our grid will work for the following use-cases:

value(8); // Just the columns count
value(from 6 to 21); // A distance from 6th column to the 21th column
value(8 min 20px max 70px); // The columns count with the lower and upper bounds of the result value
value(from 6 to 21 min 20px max 70px); // The same but with a range between columns

We have defined the two blocks of the expression: dimension and bounds. The latter is optional. Let’s dive deep into the dimension block a little bit.

The simplest case is when it equals the number - the columns count (see above). There is no more to discuss. The next variant is more difficult. It includes two mandatory keywords: from and to, and two interchangeable: start and end. The last two keywords equal to the 0 and 64 (or whatever number you decided to use) accordingly: from start to end. That expression is equal to from 0 to 64 or 100vw.
The next block has only one variant: min <number with unit> max <number with unit>. As numbers, you can use whatever value you want: pixels, rems, percentages, and so on.

That’s all. Now, when we have all rules defined, we shall go to the most exciting part - the code.

I already said that we would operate on the list of tokens, and for that purpose, we will use the list structure. Unfortunately, there are not enough methods to work with lists in SassScript. So, let’s implement missing ones.
Firstly, we need the isEmpty function to determine whether a list has tokens or not.

@function isEmpty($list) {
  @return list.length($list) == 0;
}

That function is pretty straightforward and does not require additional explanation.

Along with that, we should be able to remove processed tokens from the list. For that, we are going to implement a generic slice function.

@function slice($list, $from, $to: list.length($list) + 1) {
  $_separator: list.separator($list);
  $_copy: ();

  @for $index from $from to $to {
    $_copy: list.append($_copy, list.nth($list, $index), $_separator);
  }

  @return $_copy;
}

Fun fact: all functions that are implemented in SassScript are pure.

It reminds the code from JavaScript with the difference that the first index of the list is 1, unlike 0 in JavaScript. Also, we should preserve a separator of an original list to the sliced, and that’s all.

With that, we can start writing our main value function.

@function value($tokens) {
  $_copy: $tokens;
  $_numbers: (0, 0);
  $_borders: ();

  @if isNumber(list.nth($_copy, 1)) {
    $_numbers: (0, number($_copy));
    $_copy: slice($_copy, 2);
  } @else {
    $_numbers: range($_copy);
    $_copy: slice($_copy, 5);
  }

  @if not isEmpty($_copy) {
    $_borders: borders.borders($_copy);
  }

  @if not isEmpty($_borders) {
    @return clamp(#{list.nth($_borders, 1)}, calc(var(--unit) * #{list.nth($_numbers, 2) - list.nth($_numbers, 1)}), #{list.nth($_borders, 2)});
  }

  @return calc(var(--unit) * #{list.nth($_numbers, 2) - list.nth($_numbers, 1)});
}

Let’s stop here. That is a huge function. Because the syntax is tiny and unambiguous, we can rely on the order of tokens. We know that first is the dimension block, and the second is the borders block. The first if/else block has the code for parsing tokens of the dimension block. Also, you saw $_numbers and $_borders variables. We could define them later, but it is better to define them with a default value to avoid possible errors while using it.

You may notice that there are unknown functions: isNumber, number and range. Let’s define them.

@function isNumber($value) {
  @return meta.type-of($value) == "number";
}

@function number($list) {
  $_value: list.nth($list, 1);

  @if not isNumber($_value) {
    @error "#{$_value} is not a number!";
  }

  @return $_value;
}

isNumber, as it states from the name, checks if the value has a number type. number function takes a first token from the list and makes sure that it is a valid number.

The range function is a bit complex.

@function range($list) {
  $_copy: skip(from, $list);
  $leftNumber: toNumber(list.nth($_copy, 1));
  $_copy: skip(to, slice($_copy, 2));
  $rightNumber: toNumber(list.nth($_copy, 1));

  @if $leftNumber > $rightNumber {
    @error 'From number cannot be greater than To';
  }

  @return ($leftNumber $rightNumber + 1);
}

Simply put, this function reads tokens and checks if they are valid. There are yet other functions that we should provide: skip and toNumber.

@function toNumber($value) {
  @if $value == keywords.$start {
    @return 0;
  }

  @if $value == end {
    @return unit.$columns;
  }

  @if isNumber($value) {
    @return $value;
  }

  @error '#{$value} is not a number or "#{keywords.$start}"/"#{keywords.$end}" keywords.';
}

@function skip($word, $list) {
  @if $word != list.nth($list, 1) {
    @error 'Word #{$word} does not match the #{$list} sequence.';
  }

  @return slice($list, 2);
}

toNumber function is needed to convert start and end keywords to corresponding numbers and check whether the starting column’s value is lower than the ending column’s value. skip is just a convenient method to skip the first token in the list.

range should return starting and ending column numbers to the value to calculate an actual value.
Okay, the dimension block is ready. The borders block remains only.

@function borders($tokens) {
  $_copy: $tokens;
  $_min: 0;
  $_max: $_min;

  $_copy: skip(min, $_copy);

  $_min: list.nth($_copy, 1);

  $_copy: slice($_copy, 2);

  $_copy: skip(max, $_copy);

  $_max: list.nth($_copy, 1);

  @return ($_min, $_max);
}

Here the logic is the same as in the range function. At that point, we have a complete tiny compiler though it looks somewhat different than typical implementations. But the primary goal of this article is to show that Sass is much more powerful than it seems, and even though CSS gets many features that Sass has, the latter is still in demand.

Now, we can use our super compiler to write dimensions in the 64 columns' system.
The example of the code:

@use 'grid' as *;

.some-element {
    margin-left: value(1);
    width: value(from 1 to 8);
    height: value(3);
    background-color: tomato;
}

.some-other-element {
    width: value(from 10 to 16);
    margin-left: value(1);
    height: value(3);
    background-color: tomato;
}

That gives us simpler management of an element’s position. Thus it can be used as a simple replacement for the common grid systems. Also, it can help you to be closer to design because designers use similar grids to combine elements into the whole page.

Personally, it reminds me of a mix of Bootstrap and Susy:

The further development of that idea you can see here. There is an example page that shows simple elements positioning inside the grid. We implemented that idea on our site, that's why we can say it works and works well.

Thank you for reading, and have fun!

How to write a super simple reactive state manager

Kapelianovych Yevhen — Wed, 03 Nov 2021 08:24:53 +0000

Every application needs a state management system to have the ability to react to changes in the data. There are lots of state managers for every taste, from easy to understand ones to mind-breaking.

Do you know how they work? What principles stand behind them? I'm sure you are. But these questions I asked myself not a long time ago, and in my opinion, it is still unknown territory for beginners. So, shall we go in?

Behind most managers stands the Observer pattern. It is a powerful pattern. It says that there is a subject - a particular object encloses some data, and there are observers - objects that want to know when that data changes and what value it has now.

How will they know about the change? The subject should tell them that he is changed. For that, every observer should ask the subject to notify it when something happens. It is a subscription.

And when some data changes, the subject notifies all known observers about that. That is a notification.

Pretty simple, yeah?

Practically, there are many implementations for this pattern. We are going to show the simplest one.

Basically, the data of your application aggregates into a restricted scope. In JavaScript, we can use an object for that purpose. Each key represents a separated independent chunk of the data.

const state = {
    key1: "some useful data",
    key2: "other useful data",
    // and so on
}

We can freely read and change these chunks as we want. But the problem is that we cannot predict when the change happens and what piece is changed with what value. Simply put, the object isn't reactive. Fortunately, JavaScript has a feature that helps us track any action that is made with any object. Its name is Proxy.

Proxy is a wrapper around the object which can intercept and redefine fundamental operations for that object (MDN resource).

By default, Proxy passes through all operations to the target object. To intercept them, you need to define traps. A trap is a function whose responsibility is to redefine some operation.

All operations and their trap names you can find [here].(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/Proxy#handler_functions)

With this ability, we can write our initial store function. In the end, we should be able to do this:

const appState = store({ data: 'value' });

// Subscribe to the data changes.
appState.on('data', (newValue) => {
    // do something with a newValue
});

// Somewhere in the code
appState.data = 'updated value'; // observer is invoked

As I said earlier, the subject (our object with some data) should notify observers (some entities) when its data was changed. That can be made only when the subject knows what entities want to receive notifications. That means that the subject should have a list of observers inside.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {});
}

And now, we should define a trap for assigning a new value to the target object. That behaviour defines a set interceptor.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {
        set: (target, property, value) => {
            target[property] = value;
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(value));
            return true;
        },
    });
}

After updating the value, the subject notifies all observers that were added to the list of observers. Great! We've created a notification behaviour. But how does the subject add an observer to the subscription list?

The answer is that the subject should expose a way to trigger this subscription. With Proxy in mind, we can define a virtual method that will accomplish that process. How can we do that?

Virtual method is a method that doesn't exist in the target object, but Proxy emulates it by creating it outside of the target object.

As we know, a method is a property which value is a function. That tells us that we should define a get interceptor and provide a handler for an absent property. At the same time, we shouldn't block access to the target's properties.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {
        get: (target, property) => 
            property === 'subscribe'
                ? (key, observer) => {
                      const index = observers.push({ key, observer });
                      return () => (observers[index] = undefined);
                  }
                : target[property],
        set: (target, property, value) => {
            target[property] = value;
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(value));
            return true;
        },
    });
}

You may notice that the execution of the subscribe function returns another function. Yes, indeed. Observers should be able to stop listening to changes when they want to. That's why subscribe returns a function that will delete the listener.

And that's it! We may want to make deleting a property reactive. As we did earlier, a delete interceptor is for that.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {
        get: (target, property) => 
            property === 'subscribe'
                ? (key, observer) => {
                      const index = observers.push({ key, observer });
                      return () => (observers[index] = undefined);
                  }
                : target[property],
        set: (target, property, value) => {
            target[property] = value;
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(value));
            return true;
        },
        deleteProperty: (target, property) => {
            delete target[property];
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(undefined));
            return true;
        },
    });
}

And now our store function is complete. There are a lot of places for improvements and enhancements. And it is up to you! 🤗

Also, you can see a slightly better implementation in our @halo/store package. A code from these examples lives in the store.js file. But there is one more entity that is worth explaining. That's why we plan to write the next article precisely about it where we are going to explain the purpose of the package and in what situations you may need it. Hold tight and cheer up!

Supported by Halo Lab design-driven development agency

Kickin - bootstrap your Eleventy project

Kapelianovych Yevhen — Mon, 18 Oct 2021 16:55:52 +0000

Make your web pages fast on all devices - Developers all over the world.

We always chase productivity on our pages. And Web development community has got many instruments that help achieve this goal. Eleventy is one of them. It is a great tool that offers an easy way of combining templates and data into fully operative static pages that you can host on a server.

Unfortunately, it can bundle only templates and doesn't care about assets on the site, such as images, styles and scripts etc. So we decided to create a bundler based on Eleventy CLI 🤖
It isn't separate, but we use Eleventy's events for integration.

The primary tool is Kickin CLI. It quickly bootstraps a template folder with Eleventy and necessary plugins for comfortable development. Some of them were built by ourselves:

eleventy-plugin-compress
eleventy-plugin-pwa-icons
eleventy-plugin-scripts
eleventy-plugin-styles
eleventy-plugin-workbox
eleventy-shortcode-image

We don't recommend installing CLI globally. Instead, use a npx for project initialization.

The minimal required version of NodeJS is 12.17.0. The reason is that Kickin CLI consists of ES modules.

It exposes command that is named after itself - kickin. And its use is pretty simple.

npx kickin name-of-your-project

If you already have such a folder, you can use the . symbol instead of the name.

cd my-project-name
npx kickin .

Wait until the installation of dependencies completes, and that's all 🤗

After

There are four main commands available in the created project:

npm start - starts development server on http://localhost:3000
npm run build - builds project.
npm run serve - runs a local server with secure protocol on https://localhost:3000. It helps to mimic the production environment.
npm run certs - creates certificates for the ability to run site with HTTPS locally.

We use mkcert to generate SSL certificates. Make sure you installed it on your local machine as well.

You can change any part of the generated project as you want - configuration file and all dependencies are open to being changed.

Let's explore a little bit of what and where CLI installs.

Structure

Source code is located in the src folder.
- assets: this folder supposed to be home for static content: images, fonts, video, audio etc.
  - images
  - fonts
  - video
  - audio
- components - folder where Eleventy's components are located (default name is _includes)
- layouts - folder for layouts.
- pages - place where future site's pages live.
- scripts - folder for scripts that will be used in HTML.
- styles - folder for styles.
For bundled code, the build folder is preserved.

Inner structure of defined directories is up to you 🙃

Let's dig into plugins a little bit. There are 6 of them.

eleventy-plugin-compress

This plugin is used to compress HTML, CSS and JS using brotli(default), gzip or deflate algorithms. It helps you reduce the size of files that are sent over the internet.

Why brotli?

eleventy-plugin-pwa-icons

If you want to create PWA, you will need icons for your application for different platforms. This package uses pwa-assets-generator to create icons from an image. It will automatically insert links to icons into the HTML of every page and in the manifest.json file along with generated icons.
All you need is an image as a template for future icons. By default, it is a favicon.png under the src directory.

eleventy-plugin-scripts

Starter supports modern JavaScript syntax (except for Eleventy's templates) and TypeScript.

All scripts files should be in the scripts/ directory, but the inner structure does not matter.

To include scripts into an HTML page, provide scripts property in page template's front matter zone (can be either type of string or array of strings). The path to the script is relative to src/scripts directory, so you do not need to include this prefix in the URI.

// For JavaScript templates
module.exports.data = {
  // This will be resolved to 'src/scripts/main.js'
  scripts: 'main.js', // or 'main.ts' -> 'src/scripts/main.ts'
};

eleventy-plugin-styles

The configuration of this one is very similar to eleventy-plugin-scripts.

In Kickin Sass language is supported.

Stylesheets should be in styles/ directory, but the inner structure does not matter. They will be compiled, minified and cleaned from unused selectors automatically.

To include style to page in the template, provide styles property in front matter zone. It can be string or array of strings. The path to the stylesheet is relative to src/styles directory, so you do not need to include this prefix in the URI.

// For JavaScript templates
module.exports.data = {
  // Bundler of this starter is smart enough to recognize type of style
  // and its location (file will be resolved to `src/styles/home.scss`)
  styles: 'home.scss',
};

If you want to put your CSS file in the inner folder, say directory/common.scss , don't forget to mention it in your config:

// For JavaScript templates
module.exports.data = {
  styles: 'directory/common.scss', // -> src/styles/directory/common.scss
};

It is the most potent package of all! Whew... Amazing!

eleventy-plugin-workbox

Adds the Service worker that will automatically cache all assets of your site on a client.

Registration of service worker script will be automatically injected into each HTML page.

By default, the worker will cache static resources (images, fonts, audio files etc.) and try to use them from the cache at first. Dynamic resources that can be changed often (HTML, JS, CSS) are cached also, but on every request, it will try to fetch it on the server at first.

You can read more about strategies here.

eleventy-shortcode-image

It handles images of your page. It can properly rebase, minify and generate optimal types of images that all browsers support. It uses @11ty/eleventy-img under the hood but also can minify SVGs (uses SVGO). Compression is disabled in development mode to reduce build time. You want a quick response on your changes, aren't you? 😊 So, we do too.

For this purpose, the CLI includes an image shortcode. Use it to incorporate images to HTML (either raster or vector(SVG) ones).

Info about shortcodes and how to use them is here.

Signature of shortcode:

interface ImageAttributes {
  /** Defines alternative text for image. */
  alt?: string;
  /** Defines title for image. */
  title?: string;
  /** Class name(s) for `class` attribute. */
  classes?: string | ReadonlyArray<string>;
}

async function image(
  src: string,
  attributes?: ImageAttributes
): Promise<string>;

The first parameter is mandatory and contains an image path relative to the src/assets/images directory.

// For JavaScript templates
module.exports.render = async function () {
  return /* html */ `<main>${await this.image('logo.png')}</main>`;
};

For example, logo.png image will be resolved to src/assets/images/logo.png, then webp and avif images will be generated and placed along with the source image in the build directory. In HTML, you will receive efficient images with the correct paths 😊!

The same rules apply if you define a path to the image from CSS (for example, in the URL function). But if you specify URL as absolute (absolute public URL), it will be returned as-is without any changes.

This is done intentionally in case if you want to copy assets to the output directory.

All these packages are attached to transform flow of Eleventy.

It looks just like above. Every plugin transforms the HTML in its way and could produce new assets. Assets flow separated from Eleventy, but they are synchronised.

Configuration

The default configuration of Eleventy is enough for most use cases, but sometimes there you need to change some behaviour.

.eleventy.js is a starting point for Eleventy.

If you want to change some behaviour or add new feature to site, place it in .eleventy/ directory. It has following structure:

filters - used for holding custom filters.
plugins - contains custom plugins for Eleventy.
shortcodes - contains shortcodes
transforms - holds HTML transformer functions that changes generated HMTL by Eleventy.

Feel free to try it and give us feedback. We fell in love with these tools, and we hope you will too 🖤

Useful links:

This is a repository where a code of all plugins live.

Have fun! ✌️

Supported by Halo Lab design-driven development agency

Implementing the translate function with TypeScript

Kapelianovych Yevhen — Sun, 03 Oct 2021 15:09:31 +0000

TypeScript 4.1 has brought a nice feature called Template literal types. Many authors have written about it, so I won't stop here and explain how it works. Instead, I would like to show you an example of how we can use it. Let's not waste our time!

Every i18n module has a translate function (also can be named as short t). Assume that we have a function with such a signature:

declare function translate(path: string, variables?: Record<string, string>): string;

As the first parameter, we can pass a dot delimited keys of a translation object. It can be a JSON object or JavaScript object, whatever. The main thing is that TypeScript can't check path correctness and possible variable existence in the translated sentence with such signature. Besides, you must be careful with what you are writing. Thanks to the new feature we can fix it.

At first, we need to have a type that describes our translation object. It is up to you because no one knows how big and diversified it can be. Suppose we have it already. And our translation function should know it. Otherwise, TypeScript can't make any prediction on unknown object shapes.

declare function translate<T>(path: string, variables?: Record<string, string>): string;

But it isn't helpful yet. Let's move on. Our goal is to let TypeScript check if keys of the path parameter exist in the translation object and infer the following keys based on typed information.

We can accomplish it by creating all possible ways to structure a path to all values in the object. It may be more clear if I show it with an example.

interface T {
  a: {
     b: string;
     c: string;
    };
  d: string;
}

We have an interface T. For an object with such shape, we can build three possible path parameters:

a.b
a.c
d

And when you write a, TypeScript will add a hint that the following path part can be either .b or .c. Do you get the idea?

But how we can get all possible key combinations? We can recursively iterate over an object type and, for all top keys, get an array of all keys of inner objects that we can reach. It looks like the following:

type PathKeys<T> = T extends string ? [] : {
 [K in keyof T]: [K, ...PathKeys<T[K]>]
}[keyof T];

Stop a little bit and try to understand the type. It is a little bit tricky but works as expected. Can you see why?

Ok, we have tuples of all possible key combinations. But it isn't what we want. So we should join them to have a union type of all combinations. For that, we should learn a new type that will concatenate the values of each tuple. Let's call it Join 😎

type Join<T extends string[], Delimiter extends string> =
 T extends [] ? never :
 T extends [infer F] ? F :
 T extends [infer F, ...infer Other] ?
 F extends string ?
 `${F}${Delimiter}${Join<Extract<Other, string[]>, Delimiter>}` : never : string;

It is a bit trickier than the previous type, and we finally start using the new TypeScript feature. It accepts an array of strings (keys) and delimiter value that is the dot in our case. Then recursively iterates over the array(tuple). Unfortunately, TypeScript can't understand that the Other type is another tuple with all values except the F and infers it as unknown[], but we can fix it by providing a hack with an Extract type that narrow Other to a tuple of strings.

And that's it! Now we should make path parameter as union type of all keys combinations.

interface T {}

declare function translate<P extends Join<PathKeys<T>, '.'>>(paths: P, variables?: Record<string, string>): string;

Yay!

But one thing left. Our text can have variables, and we can provide values for them. Are we able to let TypeScript check for variable presence in translation sentences and check for name correctness? Yes, we are.

To do that, we should analyze a string and check whether it has a particular template for a variable. Suppose it is {variableName}. As the previous types, the new type will also be recursive.

type SearchForVariable<A extends string> = A extends `${infer A}{${infer B}}${infer C}`
 ? SearchForVariable<A> | B | SearchForVariable<C>
 : never;

We split a string into three parts: before a template, template itself and after the template. Returned union type will contain all variable names that exist in the string value or nothing.

But how we actually can get the correct value for checking? For that, we should match the initial translation object and path to the string value. Do you know what it means? Yes, a new type! Let's dig into it.

type Variables<T extends string | object, Path extends string, Delimiter extends string> =
 Path extends `${infer A}${Delimiter}${infer O}`
 ? A extends keyof T
 ? Variables<Extract<T[A], string | object>, O, Delimiter>
 : never
 : Path extends `${infer A}`
 ? A extends keyof T
 ? SearchForVariable<Extract<T[A], string>>
 : never
 : never;

It is the trickiest type of this tutorial. At first, we should get rid of the delimiter. Then every part of the inferred values is recursively checked. If at least one part contains a variable template, then it is returned. If there are two variables or more, then the union type of their names is the result. So, the final type of translate function looks like this:

interface T {}

declare function translate<P extends Join<PathKeys<T>, '.'>>(paths: P, variables?: Record<Variables<T, P, '.'>, string>): string;

We have built a complete translate function that TypeScript can check for correctness. You must have a concrete translation type object with values as literal string types for it to work. Otherwise, TypeScript won't make any checks 🤷‍♂️.

As a bonus, you can allow spaces between {} and variable names. But in that case, you should trim extra whitespaces from the name. A new type called Trim can help you with that.

type Trim<A extends string> = A extends ` ${infer B}` ? Trim<B> : A extends `${infer C} ` ? Trim<C> : A;

Also, you should correct the SearchForVariable type to perform the trim operation over the variable's name.

type SearchForVariable<A extends string> = A extends `${infer A}{${infer B}}${infer C}`
 ? SearchForVariable<A> | Trim<B> | SearchForVariable<C>
 : never;

A small update. And now we are finally done. The final implementation you can see here.

Thank you for reading. TypeScript is a great language and gets more power with each release. I hope you had fun and learned something new. May the wisdom be with you.

Supported by Halo Lab design-driven development agency