Creating Rules

For our demo we want to create rules regarding salary ranges for software engineers. Our salaries are dependent on the following 4 characteristics: university degree, minimum years of experience, engineer has a blog, and last year’s performance. Our generic rule looks like the following:

interface Rule {
    input: Input;
    output: Output;
}

Hence, we can define the Input as an object considering all the input variables:

interface Input {
    universityDegree: 'NONE' | 'BACHELOR' | 'MASTER';
    minimumYearsOfExperience: 0 | 2 | 5 | 8 | 10 | 15;
    hasBlog: boolean;
    lastYearsPerformance: 1 | 2 | 3 | 4 | 5;
}

Because the output should have a lower and upper salary boundary we define an Output interface with two number fields:

interface Output {
    minSalary: number;
    maxSalary: number;
}

Based on these two types we can now define the rules:

const ruleDefinitions: Rule[] = [
    {
        input: { universityDegree: 'MASTER', minimumYearsOfExperience: 8, hasBlog: false, lastYearsPerformance: 3 },
        output: { minSalary: 120_000, maxSalary: 130_000 }
    },
    {
        input: { universityDegree: 'NONE', minimumYearsOfExperience: 10, hasBlog: true, lastYearsPerformance: 4 },
        output: { minSalary: 125_000, maxSalary: 135_000 }
    }
];

We see that you don’t really need a university degree to get a good salary. If you work well and write a tech blog you can even get a higher salary than people having a master’s degree .

Evaluating Rules

The rule evaluation is simple. We just use the evaluate() method of rule-apparatus, define the input and output types, and call the method by passing the rules alongside the input arguments (here candidates):

let candidateA: Input = { universityDegree: 'MASTER', minimumYearsOfExperience: 8, hasBlog: false, lastYearsPerformance: 3 };
let candidateB: Input = { universityDegree: 'NONE', minimumYearsOfExperience: 10, hasBlog: true, lastYearsPerformance: 4 };

expect(evaluate<Input, Output>(ruleDefinitions, candidateA)).toEqual({
    minSalary: 120_000,
    maxSalary: 130_000,
});
expect(evaluate<Input, Output>(ruleDefinitions, candidateB)).toEqual({
    minSalary: 125_000,
    maxSalary: 135_000,
});

We get the expected salary ranges for our two candidates back from the evaluate method. And everything is type safe.

Rule apparatus sources and installation

These rules defined above could also be defined in a JSON format and delivered to wherever the evaluation should happen. The functionality is kept basic intentionally. There is for example no greaterThan functionality at the moment. It’s the responsibility of the consumer to define the inputs intelligently.

Please check GitHub to see the full code for this simple TypeScript rule engine. If you see any issues or potential for improvements please file an issue. The package itself can be found here on npmjs or can be installed by executing:

npm i rule-apparatus

The post Rule Apparatus – Simple TypeScript Rule Engine appeared first on Ronnie Schaniel.

type EventHandlerNameUnion = 'onChange' | 'onClick'; // and so on

While this works, it is not the best approach due to the following reasons:

• It’s cumbersome to type all the union values
• As soon as a new HTML event type is added we have to manually extend our type

Generally, we want to have low maintenance types in TypeScript. So, there has to be a better solution.

Template Literal Types to the rescue

Since we want to have a string in the end we can use template literal types to “generate” all the types:

/*
Extract from GlobalEventHandlersEventMap:

interface GlobalEventHandlersEventMap {
    ...
    "change": Event;
    "click": MouseEvent;
    ...
}
 */
type eventTypes = keyof GlobalEventHandlersEventMap;

type EventHandlerName = `on${Capitalize<eventTypes>}`;

If we hover on the type EventHandlerName we see:

We are receiving “on” followed by a capitalised event name, e.g. “Abort”. Finally we are able to detect misspellings and other issue:

The post TypeScript Coding Challenge #5 – Type for Event Handlers like onClick appeared first on Ronnie Schaniel.

type I = GetRequired<{ foo: number, bar?: string }> 
// expected to be { foo: number }

Intersection with undefined

Let’s build this step by step. What types are actually behind foo and bar? It looks as follows:

number // foo is obviously of type number
string | undefined // for bar we can either use string or undefined

An optional field basically means that the possible types are the defined type (string) or undefined. So, we need some way to detect something that can be undefined. We would like to do this with an intersection. Then we could later on check with extends. Think about the following two types:

type testFoo = number & undefined;
type testBar = (string | undefined) & undefined

An intersection of number & undefined can never happen, the type sets have no common elements. It’s different for the second case though. If we intersect (string | undefined) with undefined, the common type set is the one that contains just undefined. Our IDE helps us here as well:

What have we learnt so far? An optional field can be of a certain type or undefined. And intersection of something containing undefined with undefined itself results in undefined.

Looping through keys and checking intersection

Now let’s build the whole thing starting with the simple “key/value” type defined like:

type KeysAndValues<T> = {
    [K in keyof T]: T[K]
}
// So, nothing else than { foo: number, bar?: string }

Now let’s filter out bar? with the help of the intersection with undefined:

type II<T> = {
    [K in keyof T]: T[K] & undefined extends never ? K : never;
}

If the intersection with undefined extends never, we return the key K. In the other cases we return never. This leaves us with the following:

type IIa = II<{ foo: number, bar?: string }>;

// equal to { foo: "foo"; bar?: undefined; }

The left hand side of II<T> gives us just all the keys with [K in keyof T]. On the right hand side:

• the intersection for foo extends never and therefore we return K which is in this case the key “foo”
• for bar the intersection with undefined doesn’t extend never. So, we return never which leaves us with undefined in IIa

Putting everything together

At this moment we can determine the keys for required fields:

type RequiredKey<T> = {
    [K in keyof T]: T[K] & undefined extends never ? K : never;
}[keyof T];

type requiredKeysForI = RequiredKey<{ foo: number, bar?: string }>;
// "foo" | undefined

The expression { foo: “foo”; bar?: undefined; } accessed via keys [keyof T] gives “foo” | undefined.

Finally, we can use the required keys to construct the type:

type GetRequired<T> = {
    [K in RequiredKey<T>]: T[K];
};

If we only loop through the required keys, we only get foo. So, this finally leaves us with:

type I = GetRequired<{ foo: number, bar?: string }>

Our IDE shows us that we have found a good type to reduce something to the required fields in TypeScript:

If you’re interested in a type for chainable options, check out this post.

The post TypeScript Coding Challenge #4 – Type for Required Fields appeared first on Ronnie Schaniel.

Today we want to create types for an object with chainable method calls. Specifically, we need to provide types for two functions:

option(key, value)
get()

For key of option we can only pass strings while the value can be anything. In the end we need to provide a type or interface for Chainable as used below:

declare const config: Chainable;

const result: Result  = config
    .option('foo', 123)
    .option('name', 'type-challenges')
    .option('bar', { value: 'Hello World' })
    .get();


interface Result {
    foo: number,
    name: string,
    bar: {
        value: string
    }
}

Credits to antfu (https://github.com/type-challenges/type-challenges) for this and more great examples.

Simple solution

Let’s start by creating a simple interface Chainable with two properties that are functions. For option the key parameter is of type string while value can be any. The result of the option function is again of type Chainable. For the second method get we just define the return type Result defined above.

interface Chainable {
    option: (key: string, value: any) => Chainable,
    get: () => Result
}

When checking our IDE everything looks fine. No red squiggly lines:

The result conforms to the type Result and the methods on the Chainable config are typed. But we can do better than that.

Solution without explicit return type

The goal is always to have code that requires low maintenance and easy extension. Types are no different in that regard. We can actually enhance the types for our Chainable interface and get rid of Result. But first let’s see what happens if we remove the Result type from result.

The method get is returning {} as type and therefore also our result is of type object. Not very safe. As a consequence we also can’t access its properties:

Now let’s introduce some generics to type Chainable and our result:

interface Chainable<P = {}> {
    option<K extends string, V>(key: K, value: V): Chainable<P & { [key in K]: V }>,
    get: () => P
}

declare const config: Chainable;

const result = config
    .option('foo', 123)
    .option('name', 'type-challenges')
    .option('bar', { value: 'Hello World' })
    .get();

The Chainable interface gets a generic type parameter P with a default value. This P also “connects” the two methods. The key parameter in option is following the generic type parameter K which is constrained to string. This makes sense because this key will end up as object key for the output where we want to have string as type.
On the return side of option we make use of Intersection Types, generics and recursion. P gets “extended” with a property having key of type K and a type V.
The intersection is important to type chainable method calls in TypeScript and not lose the type from previous method calls. I first ended up with a type that only had bar as property.
Finally the method get is returning something of type P.

After that change our IDE is happy too and result is properly typed:

We not only see the properties on result (bar, foo, name) but also the type of the property ({value: string}, number, string). Hovering over result shows the complete type:

This is it for now. You’ve learnt to type chainable methods in TypeScript. Please find the sources on GitHub. If you have any questions or ideas for further TypeScript challenges, you can reach out to me on Twitter @ronnieschaniel.

The post TypeScript Coding Challenge #3 – Type Chainable Options appeared first on Ronnie Schaniel.

Implement a method that replaces repeated characters by the character and a number indicating how often the character occurs in a single repetition. To give you one example: aabcccccaaa should be compressed to a2b1c5a3. If the compressed string would not become smaller than the original one, we should return the original string. A string has only uppercase and lowercase letters (a-z).

Setup

We’re again using a custom “test function” as in our previous post about all unique characters. This time we just rename it to “assert”, change the order of the parameters and add some generics to ensure we’re working with the correct types:

function assert<I, O>(input: I, fn: (value: I) => O, expectedValue: O) {
    const result = fn(input);
    const assertionString = result === expectedValue ? '\u2713' : `\u2717 expected ${expectedValue}`;
    const color = result === expectedValue ? '\x1b[32m' : '\x1b[31m';
    console.log(color, `'${input}' => ${result} ${assertionString}`, '\x1b[0m');
}

The ‘\u2713’, etc. will ensure our output is either appearing in green or red depending on the success or failure of comparing the actual output (result) with the expectedValue. Check out this post to learn about colouring your Node JS terminal output.

Solution

We define a function that accepts a string input. First, we take care of an edge case and return the input if the string length is smaller than 3. For example the input aa with length 2 would be compressed to a2 which is unnecessary.
Now let’s take care of the remaining cases. In a for loop consecutive characters are compared and the repetitionCount is increased if the characters following each other are the same. As soon as the characters stop repeating themselves we can add the character alongside the repetitionCount to the output. At the same time we should reset the repetitionCount to the initial value of 0.
Finally we check whether the compression did really help and only return the compressed variant if it’s shorter.

function compressString(input: string): string {
    if (input.length < 3) {
        return input;
    }

    let output = '';
    let repetitionCount = 0;
    for (let i = 0; i < input.length; i++) {
        repetitionCount++;
        if (input[i] !== input[i+1]) {
            output += `${input[i]}${repetitionCount}`;
            repetitionCount = 0;
        }
    }
    return output.length < input.length ? output : input;
}

Let’s run this with a few examples:

assert('test', compressString, 'test');
assert('aabcccccaaa', compressString, 'a2b1c5a3');
assert('ttuuuz', compressString, 'ttuuuz');
assert('eeeee', compressString, 'e5');
assert('a', compressString, 'a');
assert('aa', compressString, 'aa');
assert('aaa', compressString, 'a3');
assert('', compressString, '');

This shows us the following in our console:

The first string ‘test’ is not worth compressing as it would end up being ‘t1e1s1t1’ which is not shorter than ‘test’ itself. We can get rid of a bit of string length for the second example though: ‘aabcccccaaa’ ends up as ‘a2b1c5a3’.

The post TypeScript Coding Challenge #2 – String Compression appeared first on Ronnie Schaniel.

Implement an algorithm to determine if a string has all unique characters. What if you cannot use additional data structures?

We’re going to split this into two parts. First, we start with the simple variant where we are able to use additional data structures and in the second part we can make it more difficult.

But first let’s quickly setup some code to help us test our solutions later.

Setup

As a first step we define the interface for the function that implements our solution:

fn: (value: string) => boolean

Hence, we are setting up the following testFunction to pass the input string, alongside the expected value and the function that implements our solution.

function testFunction(input: string, expectedValue: boolean, fn: (value: string) => boolean) {
    const result = fn(input);
    const assertionString = result === expectedValue ? '\u2713' : `\u2717 expected ${expectedValue}`;
    const color = result === expectedValue ? '\x1b[32m' : '\x1b[31m';
    console.log(color, `'${input}' => ${result} ${assertionString}`);
}

Solution with additional data structures

We know that in JavaScript the Set object lets you store unique values of any type, whether primitive values or object references. We can use this characteristic to solve our problem:

function hasAllUniqueCharacters(input: string): boolean {
    const characterSet = new Set(input.split(''));
    return input.length === characterSet.size;
}

We test this solution by calling our testFunction defined above:

console.log('-----------------------------------');
testFunction('test', false, hasAllUniqueCharacters);
testFunction('abc', true, hasAllUniqueCharacters);
testFunction('all', false, hasAllUniqueCharacters);
testFunction('', true, hasAllUniqueCharacters);

And in our console we can see as a result:

Everything is fine. Let’s move on to the second part of the task and tackle the variant without using any additional data structures.

Solution without additional data structures

For this solution we have to loop through the characters and compare them with each other. If we then find two identical characters and their indices are not equal (i.e. not the same character in the input) we can return false.

function hasAllUniqueCharactersV2(input: string): boolean {
    for (let i = 0; i < input.length; i++) {
        for (let j = 0; j < input.length; j++) {
            if (input[i] === input[j] && i !== j) {
                return false;
            }
        }
    }

    return true;
}

This algorithm has a time complexity of O(n²). One alternative would be to sort the input string’s characters and compare neighbouring characters. This would bring down the time complexity to O(n log n).

Anyway, testing this second function (hasAllUniqueCharactersV2) works analog to the previous one. We just pass the function as third parameter:

testFunction('test', false, hasAllUniqueCharactersV2);
// etc.

This gives us the following output in the console:

Problem solved! We have shown two possible implementations in TypeScript to determine if a string contains all unique characters.

Note: Why didn’t I use a test framework? Because for now I prefer the 4 lines of testFunction. No need to install and setup some 3rd party code.

The post TypeScript Coding Challenge #1 – All Unique Characters appeared first on Ronnie Schaniel.