DEV Community: yossarian

Handle Array.prototype.includes in TypeScript

yossarian — Thu, 10 Feb 2022 12:06:08 +0000

If you are working with typescript, sooner or later you will encounter an issue with Array.prototype.includes

const PROPS = ['a', 'b', 'c'] as const;

PROPS.includes('d') // error

const includes = (elem: string) =>
    PROPS.includes(elem) // error

I don't want to dig into type theory problem of this issue. I just will provide you with curried generic solution.

const PROPS = ['a', 'b', 'c'] as const;

const withTuple = <
    List extends string[]
>(list: readonly [...List]) =>
    (prop: string): prop is List[number] =>
        list.includes(prop)

const includes = withTuple(PROPS);

const result = includes('d')

declare let str: string

if (includes(str)) {
    str // "a" | "b" | "c"
}

However, it is still not cool. Our function works only with strings. What if we have a list of numbers or other primitives ?

First of all, we need to create utility type which will be able to convert literal type to to more wider type. I mean, it should convert literal type of 42 to number

type Primitives =
  | string
  | number
  | bigint
  | boolean
  | symbol
  | null
  | undefined

type InferPrimitive<T, P> = P extends any ? T extends P ? P : never : never;

type Inference<T> = InferPrimitive<T, Primitives>

{
  type _ = Inference<2 | 's'> // stirng | number
  type __ = Inference<42> //  number
}

Now we can use our type with curried function

type Primitives =
  | string
  | number
  | bigint
  | boolean
  | symbol
  | null
  | undefined

type InferPrimitive<T, P> = P extends any ? T extends P ? P : never : never;

type Inference<T> = InferPrimitive<T, Primitives>

{
  type _ = Inference<2 | 's'> // stirng | number
  type __ = Inference<42> //  number
}

const PROPS = ['a', 'b', 'c'] as const;

const withTuple = <
  List extends Primitives[]
>(list: readonly [...List]) =>
  (prop: Inference<List[number]>):
    prop is Inference<List[number]> & List[number] =>
    list.includes(prop)

const includes = withTuple(PROPS);

includes(2)       // expected error
includes(['str']) // expected error

const result = includes('d') // ok

declare let str: string

if (includes(str)) {
  str // "a" | "b" | "c"
}

As you might have noticed, TS allows you to call includes only with strings.

That's all.

TypeScript static validation

yossarian — Thu, 03 Feb 2022 08:47:34 +0000

I assume you are familiar with TypeScript mapped types and type inference.

In this article I will try to show you the power of static validation in TypeScript.

Validation of inferred function arguments

Let's start from a small example to better understand the approach. Imagine we have a function which expects some css width value. It may be 100px, 50vh or 10ch. Our function should do anything with argument, because we are not interested in business logic.
The naive approach would be to write this:

const units = (value: string) => { }

units('hello!') // no error

Ofcourse, this is not what we want. Our function should allow only valid css value, it means that the argument should match the pattern ${number}${unit}. Which in turn means that we need to create extra types. Let's try another one approach, more advanced:

type CssUnits = 'px' | 'vh' | '%'

const units = (value: `${number}${CssUnits}`) => { }

units('20px') // ok
units('40') // error
units('40pxx') // error

Above solution looks good. Sorry, I'm not an expert in CSS units, this is all that I know :). Please be aware that unions inside template literal strings are distributive. It means that both CssValue0 and CssValue1 are equal. More about distributive types you can find here.

type CssValue0 = `${number}${CssUnits}`;
type CssValue1 = `${number}px` | `${number}vh` | `${number}%`;

Now we can extend our requirements. What if we are no longer allowed to use % units. Let me clarify. We are allowed to use all other css units. So you should treat this rule as a negation. Please be aware that there is no negation operator in typescript. For instance we are not allowed to declare a standalone type where Data might be any type but not an "px".

type Data = not "px";

However, we can emulate this with help of inference on function arguments.

type CssUnits = 'px' | 'vh' | '%'

type CssValue = `${number}${CssUnits}`

type ForbidPx<T extends CssValue> = T extends `${number}px` ? never : T

const units = <Value extends CssValue>(value: ForbidPx<Value>) => { }

units('40%') // ok
units('40vh') // ok
units('40px') // error

As you might have noticed, there were intoroduced several important changes. First of all, I have created CssValue type which represents our css value. Second, I have added Value generic argument in order to infer provided argument. Third, I have added ForbidPx utility type which checks if a provided generic argument contains px. If you are struggling to understand template literal syntax, please check docs.

ForbidPx might be represented through this js code:

const IsRound = (str: string) => str.endsWith('px') ? null : str

Our types are still readable - it means we have not finished yet :). What would you say if we will add another one rule ? Let's say our client wants us to use only round numbers, like 100, 50, 10 and not 132, 99, 54. Not a problem.

type CssUnits = 'px' | 'vh' | '%'

type CssValue = `${number}${CssUnits}`

type ForbidPx<T extends CssValue> = T extends `${number}px` ? never : T
type IsRound<T extends CssValue> = T extends `${number}0${CssUnits}` ? T : never;


const units = <Value extends CssValue>(value: ForbidPx<Value> & IsRound<Value>) => { }

units('40%') // ok
units('401vh') // error, because we are allowed to use only rounded numbers
units('40px') // error, because px is forbidden

IsRound checks if there is 0 between the first part of css value and the last part (CssUnits). If there is 0, this utility type returns never, otherwise it returns the provided argument.

You just intersect two filters and it is done. For the sake of brevity, let's get rid of all our validators and go back to our original implementation.

type CssUnits = 'px' | 'vh' | '%'

type CssValue = `${number}${CssUnits}`

const units = <Value extends CssValue>(value: Value) => { }

Here is our new requirement. We should allow only numbers in range from 0 to 100. This requirement is a tricky one, because TS does not support any range formats of number types. However, TypeScript does support recursion. It means that we can create a union of numbers. For instance 0 | 1 | 2 | 3 .. 100. Before we do that, I will show you JavaScript representation of our algorithm:

const range = (N: number, Result: 0[] = []): 0[] => {
  if (N === Result.length) {
    return Result
  }

  return range(N, [...Result, Result.length])
}
console.log(range(5)) // [0, 0, 0, 0, 0]

I'd be willing to bet that this code is readable enough and self explanatory. Until length of Result is less than N we call range recursively with extra zero.

Let's see our implementation.

type CssUnits = 'px' | 'vh' | '%'

type CssValue = `${number}${CssUnits}`

type MAXIMUM_ALLOWED_BOUNDARY = 101

type ComputeRange<
    N extends number,
    Result extends Array<unknown> = [],
    > =
    /**
     * Check if length of Result is equal to N
     */
    (Result['length'] extends N
        /**
         * If it is equal to N - return Result
         */
        ? Result
        /**
         * Otherwise call ComputeRange recursively with updated version of Result
         */
        : ComputeRange<N, [...Result, Result['length']]>
    )

type NumberRange = ComputeRange<MAXIMUM_ALLOWED_BOUNDARY>[number]

type IsInRange<T extends CssValue> =
    /**
     * If T extends CssValue type
     */
    T extends `${infer Num}${CssUnits}`
    /**
     * and Num extends stringified union of NumberRange
     */
    ? Num extends `${NumberRange}`
    /**
     * allow using T
     */
    ? T
    /**
     * otherwise - return never
     */
    : never
    : never

const units = <Value extends CssValue>(value: IsInRange<Value>) => { }

units('100px')
units('101px') // expected error

Implementation of ComputeRange is pretty straightforward. The only limit - is TypeScript internal limits of recursion.

Maximum value of MAXIMUM_ALLOWED_BOUNDARY which is supported by TypeScript is - 999. It means that we can create a function which can validate RGB color format or IP address.

Because this article is published on css-tricks.com, I think it will be fair to validate RGB.

So, imagine you have a function which expects three arguments R, G and B accordingly.

type MAXIMUM_ALLOWED_BOUNDARY = 256

type ComputeRange<
    N extends number,
    Result extends Array<unknown> = [],
    > =
    (Result['length'] extends N
        ? Result
        : ComputeRange<N, [...Result, Result['length']]>
    )

type U8 = ComputeRange<MAXIMUM_ALLOWED_BOUNDARY>[number]

const rgb = (r: U8, g: U8, b: U8) => { }

rgb(0, 23, 255) // ok
rgb(256, 23, 255) // expected error, 256 is highlighted

Repetitive patterns

Sometimes we need a type which represents some repetitive patterns. For instance we have this string "1,2; 23,67; 78,9;". You probably have noticed that there is a pattern ${number}, ${number};. But how can we represent it in a TypeScript type system? There are two options. We either create a dummy function only for inference and validation purposes or standalone type.
Let's start with a dummy function. Why am I saying that function is dummy ? Because the only purpose of this function is to make static validation of our argument. This function does nothing at runtime, it just exists.

type Pattern = `${number}, ${number};`

type IsValid<Str extends string, Original = Str> =

    Str extends `${number},${number};${infer Rest}`
    ? IsValid<Rest, Original>
    : Str extends '' ? Original : never

const pattern = <Str extends string>(str: IsValid<Str>) => str

pattern('2,2;1,1;') // ok
pattern('2,2;1,1;;') // expected error, double semicolon ath the end

pattern('2,2;1,1;0,0') // expected error, no semicolon ath the end

While this function works, it has its own drawbacks. Every time we need a data structure with a repetitive pattern we should use an empty function just for the sake of static validation. Sometimes it is handy, but not everybody likes it.

However, we can do better. We can create a union with allowed variations of states.
Consider this example:

type Coordinates = `${number},${number};`;

type Result =
    | `${number},${number};`
    | `${number},${number};${number},${number};`
    | `${number},${number};${number},${number};${number},${number};`
    | ...

In order to do this, we should slightly modify ComputeRange utility type.

type Repeat<
    N extends number,
    Result extends Array<unknown> = [Coordinates],
    > =
    (Result['length'] extends N
        ? Result
        : Repeat<N, [...Result, ConcatPrevious<Result>]>
    )

As you might have noticed, I have added ConcatPrevious and did not provide implementation of this type by purpose. Just want to make this mess more readable. So, in fact, we are using the same algorithm with extra callback - ConcatPrevious. How do you think we should implement ConcatPrevious ? It should receive the current list and return the last element + new element. Something like this:

const ConcatPrevious = (list: string[]) => `${list[list.length-1]}${elem}`

Nothing complicated right? Let's do it in type scope.

type Coordinates = `${number},${number};`;

/**
 * Infer (return) last element in the list
 */
type Last<T extends string[]> =
    T extends [...infer _, infer Last]
    ? Last
    : never;

/**
 * Merge last element of the list with Coordinates
 */
type ConcatPrevious<T extends any[]> =
    Last<T> extends string
    ? `${Last<T>}${Coordinates}`
    : never

Now, when we have our utility types, we can write whole type:

type MAXIMUM_ALLOWED_BOUNDARY = 10

type Coordinates = `${number},${number};`;

type Last<T extends string[]> =
    T extends [...infer _, infer Last]
    ? Last
    : never;

type ConcatPrevious<T extends any[]> =
    Last<T> extends string
    ? `${Last<T>}${Coordinates}`
    : never

type Repeat<
    N extends number,
    Result extends Array<unknown> = [Coordinates],
    > =
    (Result['length'] extends N
        ? Result
        : Repeat<N, [...Result, ConcatPrevious<Result>]>
    )

type MyLocation = Repeat<MAXIMUM_ALLOWED_BOUNDARY>[number]

const myLocation1: MyLocation = '02,56;67,68;' // ok
const myLocation2: MyLocation = '45,56;67,68;1,2;3,4;5,6;7,8;9,10;' // ok
const myLocation3: MyLocation = '45,56;67,68;1,2;3,4;5,6;7,8;9,10,' // expected error no semicolon at the end

Please be aware that MyLocation is not some kind of infinitely repeated pattern. It is just a union of the maximum allowed number of elements. Feel free to increase MAXIMUM_ALLOWED_BOUNDARY until TS will throw an error. I'd be willing to bet that it should be enough for most of the cases.

How to flatten a tuple type in TypeScript?

yossarian — Sun, 12 Sep 2021 13:53:17 +0000

Every time when I need to deal with type conversion/mapping, I'm asking my self: How would I do it in pure functional language wich supports match. I mean match like in F#, ReasonML or Haskell.

Please keep in mind, that you are allowed to use only destruction and recursion. There is no filter, fold, map and other fancy methods in type system.

Wait, why am I even writing about functional languages? TypeScript is not strictly functional but, I believe, that type system is, or at least has a lot in common. For instance, you are unable to mutate type itself, you can only override it.

The function I'd like to describe is written in a little bit weird style as for typescript/javascript eco system but this is not the case.

Consider this example:

const Reducer = <T,>(
  Arr: ReadonlyArray<T>,
  Result: ReadonlyArray<T> = []
)
  : ReadonlyArray<T> => {

  if (Arr.length === 0) {
    return Result
  }
  const [Head, ...Tail] = Arr;

  if (Array.isArray(Head)) {
    return Reducer([...Head, ...Tail], Result)
  }

  return Reducer(Tail, [...Result, Head])
}

This is function works in a way we expect. It accepts [[[[[1]]]]] and returns [1].

Above function should not be hard to understand. Since we already now how to flat the tuple, let's try to make it in type system.

It works only with TS nightly

type Reducer<
  Arr extends ReadonlyArray<unknown>,
  Result extends ReadonlyArray<unknown> = []
  > =
  // if Arr is empty -> return Result
  (Arr extends readonly []
    ? Result
    // if Arr is not empty - destruct it 
    : (Arr extends readonly [infer Head, ...infer Tail]
      // check if Head is an Array
      ? (Head extends ReadonlyArray<any>
        // if it is -> call Reducer with flat Head and Tail
        ? Reducer<readonly [...Head, ...Tail], Result>
        // otherwise call Reducer with Head without flattening
        : Reducer<Tail, readonly [...Result, Head]>
      ) : never
    )
  )

As you might have noticed, I have used same algorithm as we used previously.

I just wanted to say, that if you want to write non trivial types, you need to change they way you are thinking.

I mean, if you learn some basics of F#, OCaml or any other functional language you will become better TypeScript programmer.

Let's go back to our utility type. You might want to ask me why I have used ReadonlyArray instead of regular Arrays?

This is because with ReadonlyArray it is easier to infer deep nested tuple.

See this example:

const flatten = <
  Elem,
  T extends ReadonlyArray<T | Elem>
>(arr: readonly [...T]): Reducer<T> =>
  arr.reduce((acc, elem) =>
    Array.isArray(elem)
      ? flatten(elem) as Reducer<T>
      : [...acc, elem] as Reducer<T>,
    [] as Reducer<T>
  )

// readonly [1, 2, 3]
const result = flatten([[[[[[1]]], 2], 3]] as const)

Please see my answer on stackoverflow

Sep 10 '21 Comments: 1 Answers: 2

flatten takes an array of any data type and produces an array with every nested array flatten.

For example, [{}, 'hello', 2, [3, ['ay'], 'oi oi'] becomes [{}, 'hello', 2, 3, 'ay', 'oi oi'], and [[[[5]]]] becomes [5].

I need an interface that would describe such a function…

Open Full Question

The end.

How to write a bit safer types in TypeScript

yossarian — Sat, 07 Aug 2021 20:32:33 +0000

In this article you will learn:

how to make your typescript functions even more safer
some tricky differences between types and interfaces
how to make types for your data structure more safe

Part 1 - safer functions

Consider this example which is stolen from TypeScript docs:


type Animal = { tag: 'animal' }

type Dog = Animal & { bark: true }
type Cat = Animal & { meow: true }

declare let animal: (x: Animal) => void;
declare let dog: (x: Dog) => void;
declare let cat: (x: Cat) => void;

animal = dog; // ok without strictFunctionTypes and error with

dog = animal; // should be ok

dog = cat; // should be error

Very simple code, nothing complicated.

Animal is a supertype for Dog and Cat.
There are a lot of typescript projects in the wild without strict flags. If you have active strictFunctionTypes flag, please disable it.

After disabling, you will see that animal = dog does not produces an error despite the fact that it isn’t provably sound.

This is unsound because a caller might end up being given a function that takes a more specialized type, but invokes the function with a less specialized type. In practice, this sort of error is rare, and allowing this enables many common JavaScript patterns

Of course if you have a big project you can't just turn on strictFunctionTypes and fix all errors.This is not always possible. So how to live without this flag?

Answer is simple. Just use generics.

type Animal = { tag: 'animal' }
type Dog = Animal & { bark: true }

// generic is here
declare let animal: <T extends Animal>(x: T) => void;
declare let dog: (x: Dog) => void;

animal = dog; // error even without strictFunctionTypes

Almost forgot, prefer arrow function notation inside interfaces rather than method notation:

// unsafe
interface Bivariant<T> {
  call(x: T): void
}

// safe
interface Contravariant<T> {
  call: (x: T) => void
}

Part 2 - tricky differences between types and interfaces

Imagine you have untyped handleRecord function:

interface Animal {
  tag: 'animal',
  name: 'some animal'
}

declare var animal: Animal;

const handleRecord = (obj:any) => { }

const result = handleRecord(animal)

You know that this function expects and object. You can replace any with object type, but eslint will not be happy about this change and will suggest you to use Record<string, unknown> instead.

interface Animal {
  tag: 'animal',
  name: 'some animal'
}

declare var animal: Animal;

const handleRecord = (obj:Record<string, unknown>) => { }

const result = handleRecord(animal) // error

As you might have noticed, it still does not work. Because interfaces are not indexed by the default and we still can't pass Animal object to handleRecord. So, what we can do to fix our type and don't break dependent types?

Just use type instead of interface.


type Animal= {
  tag: 'animal',
  name: 'some animal'
}

declare var animal: Animal;

const handleRecord = (obj:Record<string, unknown>) => { }

const result = handleRecord(animal) // ok

Part 3 - safer data structure
Consider this example:

interface Animals {
  dog: 'Sharky',
  cat: 'Meout'
}

type AnimalEvent<T extends keyof Animals> = {
  name: T
  call: (name: Animals[T]) => void
}

Seems that AnimalEvent constructor type is perfectly fine. Yea, why not? Let's use it as a function argument or array element:

const handleEvent = <T extends keyof Animals>(event: AnimalEvent<T>) => { }

// we would expect an error but it compiles 
const arrayOfEvents: AnimalEvent<keyof Animals>[] = [{
  name: 'dog',
  call: (name: 'Meout') => { }
}]

// should be error but it compiles
handleEvent<keyof Animals>({
  name: 'dog',
  call: (name: 'Meout') => { }
})

It is defenitely something wrong with our type because it allows us to represent invalid state. We all know that invalid state should not be representable if we use TypeScript.

Let's refactor it a bit:

interface Animals {
  dog: 'Sharky',
  cat: 'Meout'
}

type EventConstructor<T extends keyof Animals> = {
  name: T
  call: (name: Animals[T]) => void
}
/**
 * Retrieves a union of all possible values
 */
type Values<T> = T[keyof T]

// "Sharky" | "Meout"
type Test = Values<Animals>

// EventConstructor<"dog"> | EventConstructor<"cat">
type AnimalEvent = Values<{
  [Prop in keyof Animals]: EventConstructor<Prop>
}>

const handleEvent = (event: AnimalEvent) => { }

// error
const arrayOfEvents: AnimalEvent[] = [{
  name: 'dog',
  call: (name: 'Meout') => { }
}]

// error
handleEvent({
  name: 'dog',
  call: (name: 'Meout') => { }
})

Instead of using generic for animal name we have created a union of all possible AnimalEvents representation. Hence - illegal state is unrepresentable.

These techniques are easy to use and simple to understand.

Currying React components in TypeScript

yossarian — Tue, 20 Jul 2021 18:36:37 +0000

Cover image made by Victoria Smith

First of all, let me remind you what currying actually means.

const add = (x: number) => (y: number) => x + y;
const result = add(4)(2) // 6

This is all what you need to know for this moment.
Let's get straight to the point.

Consider this example:

import React, { FC } from "react";

/**
 * Converts 
 * ['hello', 'holla', 'hi']
 * into
 * {hello: 0, holla: 1, hi: 2}
 * 
 */
type ToRecord<
    T extends string[],
    Cache extends Record<string, number> = {}
    > =
    T extends []
    ? Cache
    : T extends [...infer Head, infer Last]
    ? Last extends string
    ? Head extends string[]
    ? ToRecord<
        Head, Cache & Record<Last, Head['length']>
    >
    : never
    : never
    : never

const Curry = <
    Elem extends string,
    Data extends Elem[]
>(data: [...Data]): FC<ToRecord<Data>> =>
    (props) =>
        <div>{Object.keys(props).map(elem => <p>{elem}</p>)}</div>

// FC<{ greeting: string; }>
const Result = Curry(['hello', 'holla', 'hi']) 

// hello - is a required property
const jsx = <Result hello={0} holla={1} hi={2} />

Thanks to Curry function, we can apply some constraints on our Result component. If you are curious how to infer ['hello', 'holla', 'hi'] tuple, you might be interested in my previous article.

Typescript: Type Inference on function arguments

yossarian ・ Jul 18 '21

#typescript #javascript #tutorial

ToRecord recursively iterates through each element in the tuple and accumulates each key/value in the Cache record.
Please don't focus too much on this utility type.

It looks like we can do more. What about component factory?

This example I found here

Jul 15 '21 Comments: Answers: 2

Given the type

type EnumerableComponentFactory = <C, I>(config: {
  Container: React.ComponentType<C&gt
  Item: React.ComponentType<I>;
}) => React.FC<{ items: I[] }>;

with the following implementation

const Enumerable: EnumerableComponentFactory =
  ({ Container, Item }) =>
  ({ items }) =>
    (
      <Container>
        {items.map((props, index) => (
          <Item key={index} {...props} />
        ))}
      </Container>
    );

and…

Open Full Question

import React, { FC, ComponentType } from "react";

type EnumerableComponentFactory = <I>(config: {
    Container: FC<{ children: JSX.Element[] }>;
    Item: ComponentType<I>;
}) => FC<{ items: I[] }>;

const Enumerable: EnumerableComponentFactory =
    ({ Container, Item }) =>
        ({ items }) =>
        (
            <Container>
                {items.map((props, index) => (
                    <Item key={index} {...props} />
                ))}
            </Container>
        );

const UnorderedList = Enumerable({
    Container: ({ children }) => <ul>{children}</ul>,
    Item: ({ title }: { title: string }) => <li>{title}</li>,
});

const result = <UnorderedList items={[{ title: "Something" }]} />;

It took me a bit to understand what's going on here.
So, I hope you understood the main idea. You have a function which returns a react functional components FC. First function receives some arguments. Props of returned FC depends on these arguments.

How about creating Accordeon component and writing some crazy an unreadable typings?

It should have a children with isOpen prop. Each child is also a React component that needs unique props from the parent that other children may not use. isOpen property is required for each component.
I know, it hards to understand my requirements :D.

Here you have expected behaviour:

import React, { FC } from "react";

type BaseProps = {
    isOpen: boolean;
};

const WithTitle: FC<BaseProps & { title: string }> =
    ({ isOpen, title }) => <p>{title}</p>;

const WithCount: FC<BaseProps & { count: number }> =
    ({ isOpen, count }) => <p>{count}</p>;

const Container = Curry([WithCount, WithTitle]);

/**
 * Ok
 */
const result = <Container title={"hello"} count={42} />; // ok

/**
 * Error
 */

// because [count] is string instead of number
const result_ = <Container title={"hello"} count={"42"} />;

// because second component does not expect [isOpen] property
const Container_ = Curry([WithCount, () => null]);

WithCount and WithTitle expects {title: string} and {count: number} accordingly, hence Container should expect {title: string, count: number}.

Let's start with some utility types.

First of all, we need to be able to infer props from FC<Props>

type ExtractProps<F extends FC<any>> = F extends FC<infer Props>
    ? Props
    : never;
{
    type Test = ExtractProps<FC<{ age: number }>> // { age: number }
}

Then, we need to check if every component has expected props.

type IsValid<
    Components extends Array<FC<BaseProps>>
    > =
    ExtractProps<[...Components][number]> extends BaseProps
    ? Components
    : never;
{
    type Test1 = IsValid<[FC<unknown>]> // never
    type Test2 = IsValid<[FC<BaseProps>]> //[React.FC<BaseProps>]
}

Now, we need to extract all properties from all passed components, merge them and omit isOpen, because our Result should not accept it.

// credits goes to https://stackoverflow.com/a/50375286
type UnionToIntersection<U> =
    (U extends any ? (k: U) => void : never) extends (
        k: infer I
    ) => void
    ? I
    : never;

type GetRequired<T> = UnionToIntersection<
    // make sure we have a deal with array
    T extends Array<infer F>
    ? // make sure that element in the array extends FC
    F extends FC<infer Props>
    ? // if Props extends BaseProps
    Props extends BaseProps
    ? // Omit isOpen property, since it is not needed
    Omit<Props, "isOpen">
    : never
    : never
    : never
>
{
    type Test = keyof GetRequired<[
        FC<BaseProps & { title: string }>,
        FC<BaseProps & { count: number }>
    ]> // "title" | "count"
}

We can put it all other.

import React, { FC } from "react";

type BaseProps = {
    isOpen: boolean;
};

const WithTitle: FC<BaseProps & { title: string }> =
    ({ isOpen, title }) => <p>{title}</p>
const WithCount: FC<BaseProps & { count: number }> =
    ({ isOpen, count }) => <p>{count}</p>

// credits goes to https://stackoverflow.com/a/50375286
type UnionToIntersection<U> =
    (U extends any ? (k: U) => void : never) extends (
        k: infer I
    ) => void
    ? I
    : never;

type GetRequired<T> = UnionToIntersection<
    // make sure we have a deal with array
    T extends Array<infer F>
    ? // make sure that element in the array extends FC
    F extends FC<infer Props>
    ? // if Props extends BaseProps
    Props extends BaseProps
    ? // Omit isOpen property, since it is not needed
    Omit<Props, "isOpen">
    : never
    : never
    : never
>
{
    type Test = keyof GetRequired<[
        FC<BaseProps & { title: string }>,
        FC<BaseProps & { count: number }>
    ]> // "title" | "count"
}

type ExtractProps<F extends FC<any>> = F extends FC<infer Props>
    ? Props
    : never;
{
    type Test = ExtractProps<FC<{ age: number }>> // { age: number }
}

type IsValid<
Components extends Array<FC<BaseProps>>
> =
    ExtractProps<[...Components][number]> extends BaseProps 
    ? Components 
    : never;
{
    // never
    type Test1 = IsValid<[FC<unknown>]> 
    // [React.FC<BaseProps>]
    type Test2 = IsValid<[FC<BaseProps>]> 
}

const Curry =
    <Comps extends FC<any>[], Valid extends IsValid<Comps>>(
        /**
         * If each Component expects BaseProps,
         * sections argument will evaluate to [...Comps] & [...Comps],
         * otherwise to [...Comps] & never === never
         */
        sections: [...Comps] & Valid
    ) =>
        (props: GetRequired<[...Comps]>) =>
        (
            <>
                {sections.map((Comp: FC<BaseProps>) => (
                    // isOpen is required
                    <Comp isOpen={true} {...props} />
                ))}
            </>
        );

const Container = Curry([WithCount, WithTitle]);

const result = <Container title={"hello"} count={42} />; // ok

const result_ = <Container title={"hello"} count={"42"} />; // expected error

const Container_ = Curry([WithCount, () => null]); // expected error

P.S. If you have some interesting examples of composing React components, please let me know.

The end.

Typescript: Type Inference on function arguments

yossarian — Sun, 18 Jul 2021 11:34:53 +0000

Sorry, no picture :)

In this article I will show you simple and very useful examples of type inference in TypeScript.

Part #1

Imagine you want to infer not just number type but a literal representation.
Consider next example:



const foo = <T,>(a: T) => a

// const foo: <42>(a: 42) => 42
foo(42)

T generic parameter was infered to 42 which is perfectly fine.

Now, try to pass an object: {a: 42}:



const foo = <T,>(a: T) => a

// const foo: <{ a: number; }> (a: { a: number; }) => { a: number; }
foo({ a: 42 })

This is not really what we want. We want to infer {a: 42}, not just {a: number}.

You have at least two options how to do it.
First, you can just annotate your object as immutable value. I mean as const.



foo({ a: 42 })

It works, but sometimes you are not allowed to use immutable values.
Second option is much better.
You can add extra generic yo annotate the value.



const foo = <Value, T extends { a: Value }>(a: T) => a

// const foo: <{ a: number; }> (a: { a: number; }) => { a: number; }
foo({ a: 42 })

As you might havev noticed it still does not work. In order to make it work you need apply extra restrictions to Value generic.



const foo = <Value extends number, T extends { a: Value }>(a: T) => a

// const foo: <{ a: 42; }> (a: { a: 42; }) => { a:42; }
foo({ a: 42 })

Now, it works as expected.
I know that you did not like last example. What if you want to pass an object with multiple keys. According to my example, you need to annotate each key then.

Consider next example:



const foo = <
  Key extends PropertyKey,
  Value extends number | string,
  T extends Record<Key, Value>
>(a: T) => a


// const foo: <PropertyKey, string | number, { a: 42; b: "hello";}> 
foo({ a: 42, b: 'hello' })

Now, I don't like this example, because my values are restricted to string and number types.
Instead of using string | number as a value type, we can use Json type.




type Json =
  | null
  | string
  | number
  | boolean
  | Array<JSON>
  | {
    [prop: string]: Json
  }

const foo = <
  Key extends PropertyKey,
  Value extends Json,
  T extends Record<Key, Value>
>(a: T) => a

// const foo: <PropertyKey, Json, { a: 42; b: "hello"; }
foo({ a: 42, b: 'hello' })

If you want to infer an Array instead of Record, you can do this:




type Json =
  | null
  | string
  | number
  | boolean
  | Array<JSON>
  | {
    [prop: string]: Json
  }

const foo = <
  Key extends PropertyKey,
  Value extends Json,
  T extends Record<Key, Value>[]
>(a: T) => a

// const foo: <PropertyKey, Json, { a: 42; b: "hello"; }
foo([{ a: 42, b: 'hello' }])

If your array consists of homogeneous data, you can use variadic tuples:



const foo = <
  V extends number,
  A extends { a: V }[]
>(a: [...A]) => a

foo([{ a: 1 }])

You may ask me, why I even need to infer literal type?
Because sometimes we want to validate our arguments. See my
previous article or my blog.
Imagine that you want to disallow value if it equals 1.
Try to implement this validation rule.

Part 2
What about functions ?
Consider next example:



const fn = <T,>(
  arg: {
    a: (a_arg: number) => T;
    b: (b_arg: T) => void
  }
) => null;

fn({
  a: (arg1) => ({ num: 0 }),
  b: (arg2 /** unknown */) => {
    arg2.num;
  }, // Error
});

It is obvious that argument of b method/callback/function should have return type of a. But, TS infers it as unknown.

Here you can find good explanation.

Jan 3 '21 Comments: 2 Answers: 1

My question is based on this question and answer

Let's say we have next code:

const myFn = <T,>(p: {
  a: (n: number) => T
  b: (o: T) => void,
}) => {
  // ...
}


myFn({
  a: () => ({ n: 0 }), // Parameter of a is ignored

…

Open Full Question

To make it work, you should just add extra generic:



const myFn = <T,>(arg: {
  a: (a_arg: number) => T;
  b: <U extends T>(b_arg: U) => void;
}) => {
  // ...
};

myFn({
  a: (a) => ({ num: 0 }),
  b: (b_arg) => {
    b_arg.num;
  }, // Works!
});

So, if you don't know how to infer smth, always start with adding extra generics.

If an extra generic does not help you, try to add default generic value.

Consider this example (my favourite):



class Store<T> {
  itemCreator<U>(
    generate: (item: Omit<T, keyof U>) => U
  ): (item: Omit<T, keyof U>) => Omit<T, keyof U> & U {
    return item => ({...item, ...generate(item)});
  }
}

type Person = {
  id: string;
  name: string;
  email: string;
  age?: number;
};

const create = new Store<Person>()
  .itemCreator(() => ({id: 'ID', extra: 42}));

const person = create({name: 'John', email: 'john.doe@foo.com'});

Seems, it works perfectly fine. Now, try to add an argument into itemCreator callback.



const create = new Store<Person>()
  .itemCreator((a) => ({id: 'ID', extra: 42}));

const person = create({name: 'John', email: 'john.doe@foo.com'}); // error

This example drives me crazy.
In order to fix it, you just need to move Omit<T, keyof U> outside the function:




class Store<T> {

    itemCreator<U>(
      // here I have used extra generic with default value
        generate: <P = Omit<T, keyof U>>(item: P) => U
    ): (item: Omit<T, keyof U>) => Omit<T, keyof U> & U {
        return item => ({ ...item, ...generate(item) });
    }
}


type Person = {
  id: string;
  name: string;
  email: string;
  age?: number;
};

const create = new Store<Person>()
  .itemCreator((a) => ({id: 'ID', extra: 42}));

const person = create({name: 'John', email: 'john.doe@foo.com'}); // ok

In order to understand function types, you should be aware of TypeScript contextual typing and context sensitive functions.

Can't correctly infer generic interface type when it's behind a function #25092

voliva posted on Jun 20, 2018

TypeScript Version: 2.9

Search Terms: function parameter inference

Code

interface MyInterface<T> {
    retrieveGeneric: (parameter: string) => T,
    operateWithGeneric: (generic: T) => string
}

const inferTypeFn = <T>(generic: MyInterface<T>) => generic;

// inferred type for myGeneric = MyInterface<{}>, `generic.toFixed()` marked as error (as {} doesn't have .toFixed())
const myGeneric = inferTypeFn({
    retrieveGeneric: parameter => 5,
    operateWithGeneric: generic => generic.toFixed()
});

// inferred type for myGeneric = MyInterface<number>, everything OK
const myWorkingGeneric = inferTypeFn({
    retrieveGeneric: (parameter: string) => 5,
    operateWithGeneric: generic => generic.toFixed()
});

Expected behavior: myGeneric has every type correctly inferred, parameter is a string, generic is a number.

Actual behavior: it doesn't infer the correct type for generic parameter unless you manually specify the type of parameter (which it already had the right type)

Playground Link:
https://www.typescriptlang.org/play/#src=interface%20MyInterface%3CT%3E%20%7B%0D%0A%20%20%20%20retrieveGeneric%3A%20(parameter%3A%20string)%20%3D%3E%20T%2C%0D%0A%20%20%20%20operateWithGeneric%3A%20(generic%3A%20T)%20%3D%3E%20string%0D%0A%7D%0D%0A%0D%0Aconst%20inferTypeFn%20%3D%20%3CT%3E(generic%3A%20MyInterface%3CT%3E)%20%3D%3E%20generic%3B%0D%0A%0D%0A%2F%2F%20inferred%20type%20for%20myGeneric%20%3D%20MyInterface%3C%7B%7D%3E%2C%20%60generic.toFixed()%60%20marked%20as%20error%20(as%20%7B%7D%20doesn't%20have%20.toFixed())%0D%0Aconst%20myGeneric%20%3D%20inferTypeFn(%7B%0D%0A%20%20%20%20retrieveGeneric%3A%20parameter%20%3D%3E%205%2C%0D%0A%20%20%20%20operateWithGeneric%3A%20generic%20%3D%3E%20generic.toFixed()%0D%0A%7D)%3B%0D%0A%0D%0A%2F%2F%20inferred%20type%20for%20myGeneric%20%3D%20MyInterface%3Cnumber%3E%2C%20everything%20OK%0D%0Aconst%20myWorkingGeneric%20%3D%20inferTypeFn(%7B%0D%0A%20%20%20%20retrieveGeneric%3A%20(parameter%3A%20string)%20%3D%3E%205%2C%0D%0A%20%20%20%20operateWithGeneric%3A%20generic%20%3D%3E%20generic.toFixed()%0D%0A%7D)%3B%0D%0A%0D%0A

View on GitHub

YOu can find the links inside linked SO question/answer.

Summary
1) If you don't know how to infer something, add extra generic
2) If it still does not work, try to add default values
There is high probability that such approach will help you.

Thanks.

How to type React props as a pro in TypeScript

yossarian — Sun, 11 Jul 2021 13:38:31 +0000

This article consists of 4 parts which are unrelated to each other.

Everybody who works with TypeScript and React knows how to type a props, right?

First part

Let's imagine, that we have three valid states A, B and C.



enum Mode {
  easy = 'easy',
  medium = 'medium',
  hard = 'hard'
}

type A = {
  mode: Mode.easy;
  data: string;
  check: (a: A['data']) => string
}

type B = {
  mode: Mode.medium;
  data: number;
  check: (a: B['data']) => number
}

type C = {
  mode: Mode.hard;
  data: number[];
  check: (a: C['data']) => number
}

Now, we have to make sure that our component should accept only valid props:



type Props = A | B | C;

const Comp: FC<Props> = (props) => {
  if (props.mode === Mode.easy) {
    const x = props // A
  }

  if (props.mode === Mode.medium) {
    const x = props // B
  }

  if (props.mode === Mode.hard) {
    const x = props // C
  }

  return null
}

Nothing complicated right?
Now, try to call props.check outside of condition statement.



const Comp: FC<Props> = (props) => {
  props.check(props.data) // error
  return null
}

But why error?

TL; DR;

Multiple candidates for the same type variable in contra-variant positions causes an intersection type to be inferred.

In our case:



type Intersection = string & number & number[] // never

This is why check expects never type.

Almost forgot, please dont forget about destructure, it does not play well with TS type infering:



const Comp: FC<Props> = ({ check, data, mode }) => {
  if (mode === Mode.easy) {
    check(data) // error
  }
  return null
}

If you want to use destructure - please use also typeguards.



const isEasy = <M extends Mode>(
  mode: M,
  check: Fn
): check is Extract<Props, { mode: Mode.easy }>['check'] =>
  mode === Mode.easy

Since we have added extra function to our codebase, we should test, right?

I'd like to show you the way without any extra checks.

I'm not claiming that it is safer or better option than using typeguards. In fact - it is not. You can use this approach if you don't want to provide any changes to business logic of your application. After this change, nobody will ask you to write unit tests :) Imagine situation where you just have to migrate from js to ts.

In order to allow calling check we need to overload it.
Let's split our exercise into 5 smaller taksk:

1. Get key name where property is a function.



// Get keys where value is a function
type FnProps<T> = {
  [Prop in keyof T]: T[Prop] extends Fn ? Prop : never
}[keyof T]

// check
type Result0 = FnProps<Props>

2. Get union of all functions.



type Values<T> = T[keyof T]

type FnUnion<PropsUnion> = Values<Pick<PropsUnion, FnProps<PropsUnion>>>

// | ((a: A['data']) => string) 
// | ((a: B['data']) => number) 
// | ((a: C['data']) => number)
type Result1 = FnUnion<Props>

3. Compute less specific overload



type ParametersUnion<PropsUnion> =
  FnUnion<PropsUnion> extends Fn
  ? (a: Parameters<FnUnion<PropsUnion>>[0]) =>
    ReturnType<FnUnion<PropsUnion>>
  : never

// (a: string | number | number[]) => string | number
type Result2 = ParametersUnion<Props>

4. In order to convert function union to overloads, we need to use intersection instead of union. So, lets merge our function union with less specific overload




// credits goes to https://stackoverflow.com/a/50375286
type UnionToIntersection<U> = (U extends any ? (k: U) => void : never) extends (
  k: infer I
) => void
  ? I
  : never;

type Overload<PropsUnion> =
  & UnionToIntersection<PropsUnion[FnProps<PropsUnion>]>
  & ParametersUnion<PropsUnion>

// & ((a: A['data']) => string) 
// & ((a: B['data']) => number) 
// & ((a: C['data']) => number) 
// & ((a: string | number | number[]) => string | number)
type Result3 = Overload<Props>

5. And the last step. Wee need merge our union with overloaded function. In other words, we will just override our checkproperty



type OverloadedProps<PropsUnion> =
  & PropsUnion
  & Record<FnProps<PropsUnion>, Overload<PropsUnion>>


// Props & Record<"check", Overload<Props>>
type Result4 = OverloadedProps<Props>

Full example:



import React, { FC } from 'react'

enum Mode {
  easy = 'easy',
  medium = 'medium',
  hard = 'hard'
}

type A = {
  mode: Mode.easy;
  data: string;
  check: (a: A['data']) => string
}

type B = {
  mode: Mode.medium;
  data: number;
  check: (a: B['data']) => number
}

type C = {
  mode: Mode.hard;
  data: number[];
  check: (a: C['data']) => number
}

type Fn = (...args: any[]) => any

// credits goes to https://stackoverflow.com/a/50375286
type UnionToIntersection<U> = (U extends any ? (k: U) => void : never) extends (
  k: infer I
) => void
  ? I
  : never;


type Props = A | B | C;

// Get keys where value is a function
type FnProps<T> = {
  [Prop in keyof T]: T[Prop] extends Fn ? Prop : never
}[keyof T]

// check
type Result0 = FnProps<Props>

type Values<T> = T[keyof T]

type FnUnion<PropsUnion> = Values<Pick<PropsUnion, FnProps<PropsUnion>>>

// | ((a: A['data']) => string) 
// | ((a: B['data']) => number) 
// | ((a: C['data']) => number)
type Result1 = FnUnion<Props>


type ParametersUnion<PropsUnion> =
  FnUnion<PropsUnion> extends Fn
  ? (a: Parameters<FnUnion<PropsUnion>>[0]) =>
    ReturnType<FnUnion<PropsUnion>>
  : never

// (a: string | number | number[]) => string | number
type Result2 = ParametersUnion<Props>


type Overload<PropsUnion> =
  & UnionToIntersection<PropsUnion[FnProps<PropsUnion>]>
  & ParametersUnion<PropsUnion>

// & ((a: A['data']) => string) 
// & ((a: B['data']) => number) 
// & ((a: C['data']) => number) 
// & ((a: string | number | number[]) => string | number)
type Result3 = Overload<Props>

type OverloadedProps<PropsUnion> =
  & PropsUnion
  & Record<FnProps<PropsUnion>, Overload<PropsUnion>>


// Props & Record<"check", Overload<Props>>
type Result4 = OverloadedProps<Props>

const Comp: FC<OverloadedProps<Props>> = (props) => {
  const { mode, data, check } = props;

  if (props.mode === Mode.easy) {
    props.data // string
  }

  const result = check(data) // string | number

  return null
}

Please keep in mind, this is wrong way of typing your props. Treat it as a temporary solution.

Second Part

Let's consider another example from stackoverflow

Jul 8 '21 Comments: 1 Answers: 5

I have two components with similar props, but there is a crucial difference. One component, called TabsWithState takes only a single prop tabs, which is an array of objects of the following shape:

interface ItemWithState {
  name: string
  active: boolean;
}

interface WithStateProps {
  tabs: ItemWithState[];
};

Another similar…

Open Full Question

We have two components with similar props, tabs property is common:



interface ItemWithState {
  name: string;
  active: boolean;
}

interface ItemWithRouter {
  name: string;
  path: string;
}

type WithStateProps = {
  tabs: ItemWithState[];
};

type WithRouterProps = {
  withRouter: true;
  baseUrl?: string;
  tabs: ItemWithRouter[];
};

const TabsWithRouter: FC<WithRouterProps> = (props) => null
const TabsWithState: FC<WithStateProps> = (props) => null

Also, we have higher order component:



type TabsProps = WithStateProps | WithRouterProps;

const Tabs = (props: TabsProps) => {
  if (props.withRouter) { // error
    return <TabsWithRouter {...props} />; // error
  }
  return <TabsWithState {...props} />; // error
};

We ended up with three errors.

TS will not allow you to get withRouter property, since it is optional. Instead, it allows you to get only common property which is tabs. This is expected behavior.

There is one fix/workaround. We can add withRouter?:never to our WithStateProps type.
Now it works and infers the type of {...props}. But it has one small drawback: it allows us to pass to Tabs component illegal props:



import React, { FC } from 'react'

interface ItemWithState {
  name: string;
  active: boolean;
}

interface ItemWithRouter {
  name: string;
  path: string;
}

type WithStateProps = {
  withRouter?: never;
  tabs: ItemWithState[];
};

type WithRouterProps = {
  withRouter: true;
  baseUrl?: string;
  tabs: ItemWithRouter[];
};

const TabsWithRouter: FC<WithRouterProps> = (props) => null
const TabsWithState: FC<WithStateProps> = (props) => null

type TabsProps = WithStateProps | WithRouterProps;

const Tabs = (props: TabsProps) => {
  if (props.withRouter) {
    return <TabsWithRouter {...props} />;
  }
  return <TabsWithState {...props} />;
};

const Test = () => {
  return (
    <div>
      <Tabs // With incorrect state props
        baseUrl="something"
        tabs={[{ name: "myname", active: true }]}
      />
    </div>
  );
};

This approach is bad. Let's try another one with typeguard:




interface ItemWithState {
  name: string;
  active: boolean;
}

interface ItemWithRouter {
  name: string;
  path: string;
}

type WithStateProps = {
  tabs: ItemWithState[];
};

type WithRouterProps = {
  withRouter: true;
  baseUrl?: string;
  tabs: ItemWithRouter[];
};

const TabsWithRouter: FC<WithRouterProps> = (props) => null
const TabsWithState: FC<WithStateProps> = (props) => null

type TabsProps = WithStateProps | WithRouterProps;

const hasProperty = <Obj, Prop extends string>(obj: Obj, prop: Prop)
  : obj is Obj & Record<Prop, unknown> =>
  Object.prototype.hasOwnProperty.call(obj, prop);


const Tabs = (props: TabsProps) => {
  if (hasProperty(props, 'withRouter')) {
    return <TabsWithRouter {...props} />;
  }
  return <TabsWithState {...props} />;
};

const Test = () => {
  return (
    <div>  
      <Tabs // With incorrect state props
        baseUrl="something"
        tabs={[{ name: "myname", active: true }]}
      />
    </div>
  );
};

I believe this approach is much better, because we don't need to use any hacks. Our WithStateProps type should not have any extra optional props. But it still has the same drawback. Illegal state is allowed.

Seems we forgot about function overloading. It works the same way with react components since they are just simple functions.
Please keep in mind, that intersection of functions produces overloads:




// type Overload = FC<WithStateProps> & FC<WithRouterProps>

const Tabs: FC<WithStateProps> & FC<WithRouterProps> = (props: TabsProps) => {
  if (hasProperty(props, 'withRouter')) {
    return <TabsWithRouter {...props} />;
  }
  return <TabsWithState {...props} />;
};

const Test = () => {
  return (
    <div>
      <Tabs // With correct state props
        tabs={[{ name: "myname", active: true }]}
      />
      <Tabs // With incorrect state props
        baseUrl="something"
        tabs={[{ name: "myname", active: true }]}
      />
      <Tabs // WIth correct router props
        withRouter
        tabs={[{ name: "myname", path: "somepath" }]}
      />
      <Tabs // WIth correct router props
        withRouter
        baseUrl="someurl"
        tabs={[{ name: "myname", path: "somepath" }]}
      />
      <Tabs // WIth incorrect router props
        withRouter
        tabs={[{ name: "myname", active: true }]}
      />
    </div>
  );
};

Question What if we have 5 elements in union?
Answer We can use conditional distributive types:



import React, { FC } from 'react'

interface ItemWithState {
  name: string;
  active: boolean;
}

interface ItemWithRouter {
  name: string;
  path: string;
}

type WithStateProps = {
  tabs: ItemWithState[];
};

type WithRouterProps = {
  withRouter: true;
  baseUrl?: string;
  tabs: ItemWithRouter[];
};

const TabsWithRouter: FC<WithRouterProps> = (props) => null
const TabsWithState: FC<WithStateProps> = (props) => null

type TabsProps = WithStateProps | WithRouterProps;

const hasProperty = <Obj, Prop extends string>(obj: Obj, prop: Prop)
  : obj is Obj & Record<Prop, unknown> =>
  Object.prototype.hasOwnProperty.call(obj, prop);

// credits goes to https://stackoverflow.com/a/50375286
type UnionToIntersection<U> = (U extends any ? (k: U) => void : never) extends (
  k: infer I
) => void
  ? I
  : never;

type Distributive<T> = T extends any ? FC<T> : never

type Overload = UnionToIntersection<Distributive<TabsProps>>

const Tabs: Overload = (props: TabsProps) => {
  if (hasProperty(props, 'withRouter')) {
    return <TabsWithRouter {...props} />;
  }
  return <TabsWithState {...props} />;
};

const Test = () => {
  return (
    <div>
      <Tabs // With correct state props
        tabs={[{ name: "myname", active: true }]}
      />
      <Tabs // With incorrect state props
        baseUrl="something"
        tabs={[{ name: "myname", active: true }]}
      />
      <Tabs // WIth correct router props
        withRouter
        tabs={[{ name: "myname", path: "somepath" }]}
      />
      <Tabs // WIth correct router props
        withRouter
        baseUrl="someurl"
        tabs={[{ name: "myname", path: "somepath" }]}
      />
      <Tabs // WIth incorrect router props
        withRouter
        tabs={[{ name: "myname", active: true }]}
      />
    </div>
  );
};

You can also use this approach:




type Overloading =
  & ((props: WithStateProps) => JSX.Element)
  & ((props: WithRouterProps) => JSX.Element)

This is the matter of style.

I hope you did not tired yet.

Third Part

Let's say we have Animal component with next constraints:

If dogName is empty string or unset, canBark should be false
If dogName is not empty string, canBark should be true




type NonEmptyString<T extends string> = T extends '' ? never : T;

type WithName = {
    dogName: string,
    canBark: true,
}

type WithoutName = {
    dogName?: '',
    canBark: false
};

type Props = WithName | WithoutName;

Since React component is just a regular function, we can overload it and even use some generic arguments:




type Overloadings =
    & ((arg: { canBark: false }) => JSX.Element)
    & ((arg: { dogName: '', canBark: false }) => JSX.Element)
    & (<S extends string>(arg: { dogName: NonEmptyString<S>, canBark: true }) => JSX.Element)

const Animal: Overloadings = (props: Props) => {
    return null as any
}

Let's test it:



import React, { FC } from 'react'

type NonEmptyString<T extends string> = T extends '' ? never : T;

type WithName = {
    dogName: string,
    canBark: true,
}

type WithoutName = {
    dogName?: '',
    canBark: false
};

type Props = WithName | WithoutName;


type Overloadings =
    & ((arg: { canBark: false }) => JSX.Element)
    & ((arg: { dogName: '', canBark: false }) => JSX.Element)
    & (<S extends string>(arg: { dogName: NonEmptyString<S>, canBark: true }) => JSX.Element)

const Animal: Overloadings = (props: Props) => {
    return null as any
}

const Test = () => {
    return (
        <>
            <Animal dogName='' canBark={false} /> // ok
            <Animal dogName='a' canBark={true} /> // ok
            <Animal canBark={false} /> // ok

            <Animal dogName='a' canBark={false} /> // error
            <Animal dogName='' canBark={true} /> // error
            <Animal canBark={true} /> // error
        </>
    )
}

Fourth part

Let's say we have a component which expects foo and bar properties to be strings, but property foo can't be hello.

In order to do it, we should use explicit generic for foo and bar property.
This is easy:



import React from 'react'


type Props<F extends string = '', B extends string = ''> = {
    foo: F;
    bar: B;
}

type ConditionalProps<T> = T extends { foo: infer Foo; bar: string } ? Foo extends 'hello' ? never : T : never

const Example = <F extends string, B extends string>(props: ConditionalProps<Props<F, B>>) => {
    return null as any
}


const Test = () => {
    <>
        <Example foo='hello' bar='bye' /> // expected error
        <Example foo='not hello' bar='1' /> // ok
    </>

}

Thanks for the reading.

Mutations in TypeScript

yossarian — Wed, 30 Jun 2021 18:26:15 +0000

In this article, I will describe some problems you can encounter mutating objects in typescript.

I have noticed that few people on StackOverflow had issues with mutations in typescript.

Most of the time, it looks like a bug for us, but it is not.

Let's start from type system itself.



type User = {
    name: string;
}

Is it possible to mutate this type?

How would you change the type of name property to number?

There are several ways to do this:



type User = {
    name: string;
}

type User1 = User & {
    name: number;
}

type User2 = {
    [P in keyof User]: P extends 'name' ? number : User[P]
}

type User3 = Omit<User, 'name'> & { name: number }

As you might have noticed, non of them mutate the type, only overrides the property.

I think this is the most natural way of dealing with objects in TypeScript.

First and foremost, you should definitely watch Titian-Cernicova-Dragomir's talk about covariance and contravariance in TypeScript.

This example, is shamelessly stolen from Titian's talk



type Type = {
    name: string
}

type SubTypeA = Type & {
    salary: string
}

type SubTypeB = Type & {
    car: boolean
}

type Extends<T, U> =
    T extends U ? true : false


let employee: SubTypeA = {
    name: 'John Doe',
    salary: '1000$'
}

let human: Type = {
    name: 'Morgan Freeman'
}

let student: SubTypeB = {
    name: 'Will',
    car: true
}


// same direction
type Covariance<T> = {
    box: T
}

let employeeInBox: Covariance<SubTypeA> = {
    box: employee
}

let humanInBox: Covariance<Type> = {
    box: human
}

/**
 * MUTATION 
 */
let test: Covariance<Type> = employeeInBox

test.box = student // mutation of employeeInBox

// while result_0 is undefined, it is infered a a string
const result_0 = employeeInBox.box.salary 


/**
 * MUTATION
 */
let array: Array<Type> = []
let employees = [employee]
array = employees
array.push(student)

// while result_1  is [string, undefined], it is infered as string[]
const result_1 = employees.map(elem => elem.salary)

There is a lot going on here.

If you are curious how to avoid such behavior, all you need is to make values immutable.

Try to add readonly flag to Covariance and use ReadonlyArray



type Covariance<T> = {
   readonly box: T
}

let array: ReadonlyArray<Type> = []

However, if you are planning to mutate your objects, you should be aware about some issues you can face.

First issue



interface InjectMap {
    "A": "B",
    "C": "D"
}
type InjectKey = keyof InjectMap;

const input: Partial<InjectMap> = {};
const output: Partial<InjectMap> = {};

const keys: InjectKey[] = []


for (let i = 0; i < keys.length; i++) {
    const key = keys[i];

    const inp = input[key] // "B" | "D" | undefined
    const out = output[key] // "B" | "D" | undefined

    output[key] = input[key] // error

}

It is might be not obvious, but this is expected behavior.

While both input and output share same type, they could have different value.



type KeyType_ = "B" | "D" | undefined

let keyB: KeyType_ = 'B';
let keyD: KeyType_ = 'D'

output[keyB] = input[keyD] // Boom, illegal state! Runtime error!

Second example




const foo = <T extends { [key: string]: any }>(obj: T) => {
    obj['a'] = 2 // error
}

This behavior is expected, because mutating obj argument can lead to runtime errors.




let index: { [key: string]: any } = {}

let immutable = {
    a: 'a'
} as const

let record: Record<'a', 1> = { a: 1 }

index = immutable // ok
index = record // ok

const foo = <T extends { [key: string]: any }>(obj: T) => {
    obj['a'] = 2 // error

    return obj
}

const result1 = foo(immutable) //  unsound, see return type 
const result2 = foo(record) // unsound , see return type

As you see, TS has some mechanisms to avoid unsound mutations. But, unfortunately, it is not enough.

Try to use Reflect.deleteProperty or delete operator



let index: { [key: string]: any } = {}

let immutable = {
  a: 'a'
} as const

let record: Record<'a', 1> = { a: 1 }

index = immutable // ok
index = record // ok

const foo = <T extends { [key: string]: any }>(obj: T) => {
  Reflect.deleteProperty(obj, 'a') // or delete obj.a

  return obj
}

const result1 = foo(immutable) //  unsound, see return type 
const result2 = foo(record) // unsound , see return type

However, we still can't remove property from object which has explicit type:



type Foo = {
  age: number
}

const foo: Foo = { age: 42 }

delete foo.age // error

Third issue

Consider this example:



const paths = ['a', 'b'] as const

type Path = typeof paths[number]

type PathMap = {
    [path in Path]: path
}

const BASE_PATHS = paths.reduce((map: PathMap, p: Path) => {
    let x = map[p]
    map[p] = p // error
    return map
}, {} as PathMap)

Here you see an error because objects are contravariant in their key types

What does it mean ?

Multiple candidates for the same type variable in contra-variant positions causes an intersection type to be inferred.

Simple example:




type a = 'a'
type b = 'b'

type c = a & b // never

Official explanation:

Improve soundness of indexed access types #30769

ahejlsberg posted on Apr 05, 2019

With this PR we improve soundness of indexed access types in a number of ways:

When an indexed access T[K] occurs on the source side of a type relationship, it resolves to a union type of the properties selected by T[K], but when it occurs on the target side of a type relationship, it now resolves to an intersection type of the properties selected by T[K]. Previously, the target side would resolve to a union type as well, which is unsound.
Given a type variable T with a constraint C, when an indexed access T[K] occurs on the target side of a type relationship, index signatures in C are now ignored. This is because a type argument for T isn't actually required to have an index signature, it is just required to have properties with matching types.
A type { [key: string]: number } is no longer related to a mapped type { [P in K]: number }, where K is a type variable. This is consistent with a string index signature in the source not matching actual properties in the target.
Constraints of indexed access types are now more thoroughly explored. For example, given type variables T and K extends 'a' | 'b', the types { a: T, b: T }[K] and T are now considered related where previously they weren't.

Some examples:

function f1(obj: { a: number, b: string }, key: 'a' | 'b') {
    obj[key] = 1;    // Error
    obj[key] = 'x';  // Error
}

function f2(obj: { a: number, b: 0 | 1 }, key: 'a' | 'b') {
    obj[key] = 1;
    obj[key] = 2;  // Error
}

function f3<T extends { [key: string]: any }>(obj: T) {
    let foo = obj['foo'];
    let bar = obj['bar'];
    obj['foo'] = 123;  // Error
    obj['bar'] = 'x';  // Error
}

function f4<K extends string>(a: { [P in K]: number }, b: { [key: string]: number }) {
    a = b;  // Error
    b = a;
}

Previously, none of the above errors were reported.

Fixes #27895. Fixes #30603.

View on GitHub

Btw, for similar reason you have this error:




type A = {
  data: string;
  check: (a: A['data']) => string
}

type B = {
  data: number;
  check: (a: B['data']) => number
}

type C = {
  data: number[];
  check: (a: C['data']) => number
}

type Props = A | B | C;

const Comp = (props: Props) => {
  // check(a: never): string | number
  props.check()

  return null
}

Because function arguments are in contravariant position they are cause intersection.

Composition of type validators in TypeScript

yossarian — Tue, 22 Jun 2021 18:14:13 +0000

In this article, You can find some type validation techniques.

Let's start with simple function

Assume, our function argument should be always some CSS value. For example: 100px, 10rem, 50% etc ...

First of all we should check if value ends with some allowed measure units:

type Units = 'px' | 'rem' | '%';

Now, we should be able to split our measure units into two parts: number and unit


type Units = 'px' | 'rem' | '%';

type IsValidCSS<T extends string> = T extends `${number}${Units}` ? true : false;

type Result = IsValidCSS<'10px'> // true
type Result2 = IsValidCSS<'10p'> // false

Lets write generic validator:

type Units = 'px' | 'rem' | '%';

type IsValidCSS<T extends string> = T extends `${number}${Units}` ? true : false;

type Validator<T extends boolean> = T extends true ? [] : [never];

type Test = Validator<IsValidCSS<'10px'>> // []

Please, give me a minute, I will explain why we need an array as a return type from Validator

Let's try it

const foo = <T,>(arg: T, ...validation: Validator<IsValidCSS<T>>) => {}

foo('10px'); // error

Still does not work, because argument is infered to string instead of literal 10px.

In order to fix it, we should apply additional constraints to the generic type:

const foo = <T extends string>(arg: T, ...validation: Validator<IsValidCSS<T>>) => {}

foo('10px'); // ok
foo('10%'); // ok
foo('10p'); // error

Is it possible to apply several validators?

Assume, we are not allowed to use 99 in our CSS

type Units = 'px' | 'rem' | '%';

type IsValidCSS<T> = T extends `${number}${Units}` ? true : false;

type StringNumber<T extends number> = `${T}`;

type IsAllowedNumber<T> = 
  T extends `${infer Num}${Units}` 
  ? Num extends StringNumber<99> 
  ? false 
  : true 
  : false;

type Validator<T extends boolean> = 
  T extends true 
  ? [] 
  : ['Dear developer, please use valid CSS values'];

const foo = <T extends string>
  (
    arg: T,
    ...validation: [...Validator<IsValidCSS<T>>, ...Validator<IsAllowedNumber<T>>]
  ) => { }

foo('100px'); // ok
foo('99px'); // expected error

Each time, when Validator fails, it returns [never] and because we are using rest operator it evaluates to never.

So if Validator has failed, TS expects second argument which is never.

That's all.

Typing compose function in TypeScript

yossarian — Tue, 22 Jun 2021 18:07:42 +0000

Let's write some crazy, unreadable and unmaintainable typings for compose function. Maybe you will learn smth new.

Let's define some base types and utils.

type Fn = (a: any) => any

type Head<T extends any[]> =
    T extends [infer H, ...infer _]
    ? H
    : never;

type Last<T extends any[]> =
    T extends [infer _]
    ? never : T extends [...infer _, infer Tl]
    ? Tl
    : never;

type Foo = typeof foo
type Bar = typeof bar
type Baz = typeof baz

Our main goal is to make compose without any arguments length restriction.

For example, take a look on lodash compose typings:


    interface LodashFlowRight {
        <A extends any[], R1, R2, R3, R4, R5, R6, R7>(f7: (a: R6) => R7, f6: (a: R5) => R6, f5: (a: R4) => R5, f4: (a: R3) => R4, f3: (a: R2) => R3, f2: (a: R1) => R2, f1: (...args: A) => R1): (...args: A) => R7;
        <A extends any[], R1, R2, R3, R4, R5, R6>(f6: (a: R5) => R6, f5: (a: R4) => R5, f4: (a: R3) => R4, f3: (a: R2) => R3, f2: (a: R1) => R2, f1: (...args: A) => R1): (...args: A) => R6;
        <A extends any[], R1, R2, R3, R4, R5>(f5: (a: R4) => R5, f4: (a: R3) => R4, f3: (a: R2) => R3, f2: (a: R1) => R2, f1: (...args: A) => R1): (...args: A) => R5;
        <A extends any[], R1, R2, R3, R4>(f4: (a: R3) => R4, f3: (a: R2) => R3, f2: (a: R1) => R2, f1: (...args: A) => R1): (...args: A) => R4;
        <A extends any[], R1, R2, R3>(f3: (a: R2) => R3, f2: (a: R1) => R2, f1: (...args: A) => R1): (...args: A) => R3;
        <A extends any[], R1, R2>(f2: (a: R1) => R2, f1: (...args: A) => R1): (...args: A) => R2;
        (...func: Array<lodash.Many<(...args: any[]) => any>>): (...args: any[]) => any;
    }

There is a limit for arguments.

Let's try to write function without any limits, at least explicit limits. Please keep in mind TS has his own recursion limits, so we have to live with that

I will start with validation logic:

type Allowed<
    T extends Fn[],
    Cache extends Fn[] = []
    > =
    T extends []
    ? Cache
    : T extends [infer Lst]
    ? Lst extends Fn
    ? Allowed<[], [...Cache, Lst]> : never
    : T extends [infer Fst, ...infer Lst]
    ? Fst extends Fn
    ? Lst extends Fn[]
    ? Head<Lst> extends Fn
    ? Head<Parameters<Fst>> extends ReturnType<Head<Lst>>
    ? Allowed<Lst, [...Cache, Fst]>
    : never
    : never
    : never
    : never
    : never;

Above type iterates through every function in the array and checks if argument of current function is assignable to return type of next function Head<Parameters<Fst>> extends ReturnType<Head<Lst>>

Next, we can define simple helpers:


type LastParameterOf<T extends Fn[]> =
    Last<T> extends Fn
    ? Head<Parameters<Last<T>>>
    : never

type Return<T extends Fn[]> =
    Head<T> extends Fn
    ? ReturnType<Head<T>>
    : never

Finally, our compose function:


function compose<T extends Fn, Fns extends T[], Allow extends {
    0: [never],
    1: [LastParameterOf<Fns>]
}[Allowed<Fns> extends never ? 0 : 1]>
    (...args: [...Fns]): (...data: Allow) => Return<Fns>

function compose<
    T extends Fn,
    Fns extends T[], Allow extends unknown[]
>(...args: [...Fns]) {
    return (...data: Allow) =>
        args.reduceRight((acc, elem) => elem(acc), data)
}

As you might have noticed, I have defined only one overload, this is considered a bad practice. We should always define at least two. Sorry for that.

And full example for copy/paste:


type Foo = typeof foo
type Bar = typeof bar
type Baz = typeof baz


type Fn = (a: any) => any

type Head<T extends any[]> =
    T extends [infer H, ...infer _]
    ? H
    : never;

type Last<T extends any[]> =
    T extends [infer _]
    ? never : T extends [...infer _, infer Tl]
    ? Tl
    : never;


type Allowed<
    T extends Fn[],
    Cache extends Fn[] = []
    > =
    T extends []
    ? Cache
    : T extends [infer Lst]
    ? Lst extends Fn
    ? Allowed<[], [...Cache, Lst]> : never
    : T extends [infer Fst, ...infer Lst]
    ? Fst extends Fn
    ? Lst extends Fn[]
    ? Head<Lst> extends Fn
    ? Head<Parameters<Fst>> extends ReturnType<Head<Lst>>
    ? Allowed<Lst, [...Cache, Fst]>
    : never
    : never
    : never
    : never
    : never;

type LastParameterOf<T extends Fn[]> =
    Last<T> extends Fn
    ? Head<Parameters<Last<T>>>
    : never

type Return<T extends Fn[]> =
    Head<T> extends Fn
    ? ReturnType<Head<T>>
    : never


function compose<T extends Fn, Fns extends T[], Allow extends {
    0: [never],
    1: [LastParameterOf<Fns>]
}[Allowed<Fns> extends never ? 0 : 1]>
    (...args: [...Fns]): (...data: Allow) => Return<Fns>

function compose<
    T extends Fn,
    Fns extends T[], Allow extends unknown[]
>(...args: [...Fns]) {
    return (...data: Allow) =>
        args.reduceRight((acc, elem) => elem(acc), data)
}

const foo = (arg: 1 | 2) => [1, 2, 3]
const bar = (arg: string) => arg.length > 10 ? 1 : 2
const baz = (arg: number[]) => 'hello'

const check = compose(foo, bar, baz)([1, 2, 3]) // [number]
const check2 = compose(bar, foo)(1) // expected error

Typing deep pick function in TypeScript

yossarian — Tue, 22 Jun 2021 18:01:35 +0000

In this article I will try to implement something similar to lodash.get function.

This is what I want to implement:

// John
const result = deepPick({ user: { name: 'John' } }, 'user', 'name')

First of all, we should validate all arguments but first, because they should be in right order. Let's assume we have next object:

type Foo = {
    user: {
        description: {
            name: string;
            surname: string;
        }
    }
}

Now, we need to generate array of all allowed keys.In order to do that, we need to iterate through every key and replace type property with array of keys.

Does it make sense for You?

type FirstAttempt<T> = {
    [P in keyof T]: [P]
}

Above code does not make any sense. We need to iterate through every nested property, hence, we need to make it recursively. Let's try again. But now, we need call recursion only if property is not primitive.


type SecondAttempt<Obj> = {
    [Prop in keyof Obj]:
    Obj[Prop] extends PropertyKey
    ? [Prop]
    : SecondAttempt<Obj[Prop]>
}

// { name: ["name"]; surname: ["surname"]; }
type Result = SecondAttempt<Foo>['user']['description']

It is looks better now, but we did not receive full path to name and surname. We only have an array of last non primitive property.

Seems, we need some cache.

type ThirdAttempt<Obj, Cache extends Array<PropertyKey> = []> = {
    [Prop in keyof Obj]: Obj[Prop] extends PropertyKey
    ? [...Cache, Prop]
    : ThirdAttempt<Obj[Prop], [...Cache, Prop]>
}

// {
//     name: ["user", "description", "name"];
//     surname: ["user", "description", "surname"];
// }
type Result = ThirdAttempt<Foo>['user']['description']

Looks a way better now. But we need all possible values. User should be able to get not only primitive values. We should allow user to get ['user', 'description']

We can try to pass Cache as a union of previous and next type.

type FourthAttempt<Obj, Cache extends Array<PropertyKey> = []> = {
    [Prop in keyof Obj]: Obj[Prop] extends PropertyKey
    ? [...Cache, Prop]
    : FourthAttempt<Obj[Prop], Cache | [...Cache, Prop]>
}

type Result = FourthAttempt<Foo>['user']['description']

Seems we are closer now. Pls keep in mind, we still need a union of arrays instead of some weird object. Btw, it is still does not meet our requirements

Let's move our condition statement one level up.


type FifthAttempt<Obj, Cache extends Array<PropertyKey> = []> =
    Obj extends PropertyKey
    ? Cache
    : {
        [Prop in keyof Obj]:
        FifthAttempt<Obj[Prop], Cache | [...Cache, Prop]>
    }

type Result = FifthAttempt<Foo>

Assume we have our union of arrays in one place, as a value of deepest keys. How we can get it? I'd willing to bet that You are aware of famous utility type type Values<T>=T[keyof T]

type Values<Obj> = Obj[keyof Obj]

type SixthAttempt0<Obj, Cache extends Array<PropertyKey> = []> =
    Obj extends PropertyKey
    ? Cache
    : Values<{
        [Prop in keyof Obj]:
        SixthAttempt0<Obj[Prop], Cache | [...Cache, Prop]>
    }>

type Result = SixthAttempt0<Foo>

We still have a logical error in our code. Let's fix it.

type FinalAttempt<Obj, Cache extends Array<PropertyKey> = []> =
    Obj extends PropertyKey
    ? Cache
    : {
        [Prop in keyof Obj]:
        | [...Cache, Prop]
        | FinalAttempt<Obj[Prop], [...Cache, Prop]>
    }[keyof Obj]

type Result = FinalAttempt<Foo>

Finally we did it. Are You bored? Feel free to make a break.

So far we did only 50% of our work. Let's test it.

type FinalAttempt<Obj, Cache extends Array<PropertyKey> = []> =
    Obj extends PropertyKey ? Cache : {
        [Prop in keyof Obj]:
        | [...Cache, Prop]
        | FinalAttempt<Obj[Prop], [...Cache, Prop]>
    }[keyof Obj]

declare function deepPick<Obj,>(obj: Obj, ...keys: FinalAttempt<Obj>): void
declare var foo: Foo;

deepPick(foo, 'user'); // ok
deepPick(foo, 'user', 'description') // ok
deepPick(foo, 'description') // expected error

What about our ReturnType?

Btw, if You will try to write implementation for this function, You will get an errors:

function deepPick<Obj >(obj: Obj, ...keys: FinalAttempt<Obj>){
    return keys.reduce((acc,elem)=>acc[elem], obj) // <-- errors
}

In order to make it work, we should assure TS that keys has not any problems with infinity recursion and it is an array of strings. Further more, how would you type reducer predicate? Since, every iteration it returns different type.

We can type it in same way we typed union of keys (FinalAttempt), but this time let's make a union of values. It returns all combinations of Foo values.

type ValuesUnion<Obj, Cache = Obj> =
    Obj extends Primitives ? Obj : Values<{
        [Prop in keyof Obj]:
        | Cache | Obj[Prop]
        | ValuesUnion<Obj[Prop], Cache | Obj[Prop]>
    }>

I also used here simple hasProperty typeguard.

const hasProperty = <Obj, Prop extends Primitives>(obj: Obj, prop: Prop)
    : obj is Obj & Record<Prop, any> =>
    Object.prototype.hasOwnProperty.call(obj, prop);

function deepPick<Obj, Keys extends FinalAttempt<Obj> & Array<string>>
    (obj: ValuesUnion<Obj>, ...keys: Keys) {
    return keys
        .reduce(
            (acc, elem) => hasProperty(acc, elem) ? acc[elem] : acc,
            obj
        )
}

Let's write type for picking the object property. I decided to implement deep picking exactly how we did it in a function. I think it will help You to understand how does it work under the hood. Ok, ok, You cought me. I just don't know how to do it in other way :)

type Elem = string;

type Acc = Record<string, any>

// (acc, elem) => hasProperty(acc, elem) ? acc[elem] : acc
type Predicate<Accumulator extends Acc, El extends Elem> =
    El extends keyof Accumulator ? Accumulator[El] : Accumulator

type Reducer<
    Keys extends ReadonlyArray<Elem>,
    Accumulator extends Acc = {}
    > =
    /**
     *  If Keys is empty array, no need to call recursion, 
     *  just return Accumulator
     */
    Keys extends []
    ? Accumulator
    /**
     * If keys is one element array,
     * 
     */
    : Keys extends [infer H]
    ? H extends Elem
    /**
     * take this element and call predicate 
     */
    ? Predicate<Accumulator, H>
    : never
    /**
     * If Keys is an Array of more than one element
     */
    : Keys extends readonly [infer H, ...infer Tail]
    ? Tail extends ReadonlyArray<Elem>
    ? H extends Elem
    /**
     * Call recursion with Keys Tail
     * and call predicate with first element 
     */
    ? Reducer<Tail, Predicate<Accumulator, H>>
    : never
    : never
    : never;

If it is hard to understand what I did here, no worries, it is hard for me either.

Here you have pure js analogy:

const reducer = (keys: string[], accumulator: Record<string, any> = {}) => {
    const predicate = (obj,prop)=>obj[prop]

    if (keys.length === 0) {
        return accumulator;
    }
    if (keys.length === 1) {
        const [head] = keys;
        return reducer([], predicate(accumulator, head))
    }

    if(keys.length>1){
        const [head, ...tail]=keys;
        return reducer(tail, predicate(accumulator, head))
    }
}

Ok, we are done. Here is the full code:

type Foo = {
    user: {
        description: {
            name: string;
            surname: string;
        }
    }
}

declare var foo: Foo;

/**
 * Common utils
 */

type Primitives = string | number | symbol;

type Values<T> = T[keyof T]

type Elem = string;

type Acc = Record<string, any>

// (acc, elem) => hasProperty(acc, elem) ? acc[elem] : acc
type Predicate<Accumulator extends Acc, El extends Elem> =
    El extends keyof Accumulator ? Accumulator[El] : Accumulator

type Reducer<
    Keys extends ReadonlyArray<Elem>,
    Accumulator extends Acc = {}
    > =
    /**
     *  If Keys is empty array, no need to call recursion, 
     *  just return Accumulator
     */
    Keys extends []
    ? Accumulator
    /**
     * If keys is one element array,
     * 
     */
    : Keys extends [infer H]
    ? H extends Elem
    /**
     * take this element and call predicate 
     */
    ? Predicate<Accumulator, H>
    : never
    /**
     * If Keys is an Array of more than one element
     */
    : Keys extends readonly [infer H, ...infer Tail]
    ? Tail extends ReadonlyArray<Elem>
    ? H extends Elem
    /**
     * Call recursion with Keys Tail
     * and call predicate with first element 
     */
    ? Reducer<Tail, Predicate<Accumulator, H>>
    : never
    : never
    : never;

const hasProperty = <Obj, Prop extends Primitives>(obj: Obj, prop: Prop)
    : obj is Obj & Record<Prop, any> =>
    Object.prototype.hasOwnProperty.call(obj, prop);


/**
 * Fisrt approach
 * 
 */

type KeysUnion<T, Cache extends Array<Primitives> = []> =
    T extends Primitives ? Cache : {
        [P in keyof T]:
        | [...Cache, P]
        | KeysUnion<T[P], [...Cache, P]>
    }[keyof T]

type ValuesUnion<T, Cache = T> =
    T extends Primitives ? T : Values<{
        [P in keyof T]:
        | Cache | T[P]
        | ValuesUnion<T[P], Cache | T[P]>
    }>

function deepPickFinal<Obj, Keys extends KeysUnion<Obj> & ReadonlyArray<string>>
    (obj: ValuesUnion<Obj>, ...keys: Keys): Reducer<Keys, Obj>

function deepPickFinal<Obj, Keys extends KeysUnion<Obj> & Array<string>>
    (obj: ValuesUnion<Obj>, ...keys: Keys) {
    return keys
        .reduce(
            (acc, elem) => hasProperty(acc, elem) ? acc[elem] : acc,
            obj
        )
}

/**
 * Ok
 */
const result = deepPickFinal(foo, 'user') // ok
const result2 = deepPickFinal(foo, 'user', 'description') // ok
const result3 = deepPickFinal(foo, 'user', 'description', 'name') // ok
const result4 = deepPickFinal(foo, 'user', 'description', 'surname') // ok

/**
 * Expected errors
 */
const result5 = deepPickFinal(foo, 'surname')
const result6 = deepPickFinal(foo, 'description')
const result7 = deepPickFinal(foo)

There is another approach to do it. It requires to use validation technique.

I know, naming is awful :) I don't know how to name it in more meaningful way.

type Foo = {
    user: {
        description: {
            name: string;
            surname: string;
        }
    }
}

declare var foo: Foo;

type Primitives = string | number | symbol;


type Util<Obj, Props extends ReadonlyArray<Primitives>> =
    Props extends []
    ? Obj
    : Props extends [infer First]
    ? First extends keyof Obj
    ? Obj[First]
    : never
    : Props extends [infer Fst, ...infer Tail]
    ? Fst extends keyof Obj
    ? Tail extends string[]
    ? Util<Obj[Fst], Tail>
    : never
    : never
    : never

// credits https://github.com/microsoft/TypeScript/issues/23182#issuecomment-379091887
type IsNeverType<T> = [T] extends [never] ? true : false;

type IsAllowed<T> = IsNeverType<T> extends true ? false : true;
type Validator<T extends boolean | string> = T extends true ? [] : [never]
type ValuesUnion<T, Cache = T> =
    T extends Primitives ? T : {
        [P in keyof T]:
        | Cache | T[P]
        | ValuesUnion<T[P], Cache | T[P]>
    }[keyof T]

const hasProperty = <Obj, Prop extends Primitives>(obj: Obj, prop: Prop)
    : obj is Obj & Record<Prop, any> =>
    Object.prototype.hasOwnProperty.call(obj, prop);


function pick<
    Obj,
    Prop extends string,
    Props extends ReadonlyArray<Prop>,
    Result extends Util<Obj, Props>>
    (
        obj: ValuesUnion<Obj>,
        props: [...Props],
        ..._: Validator<IsAllowed<Result>>
    ): Util<Obj, Props>;

function pick<
    Obj,
    Prop extends string,
    Props extends ReadonlyArray<Prop>,
    Result extends Util<Obj, Props>>(
        obj: ValuesUnion<Obj>,
        props: [...Props],
        ..._: Validator<IsAllowed<Result>>) {
    return props.reduce(
        (acc, prop) => hasProperty(acc, prop) ? acc[prop] : acc,
        obj
    )
}

/**
 * Ok
 */
const result8 = pick(foo, ['user', 'description']) // ok
const result9 = pick(foo, ['user', 'description', 'name']) // ok

/**
 * Expected errors
 */

const result10 = pick(foo, ['description']) // error
const result11 = pick(foo, ['name']) // ok

That's all. Thanks you

Using fetch in TypeScript with typestate pattern

yossarian — Fri, 30 Oct 2020 22:15:23 +0000

If You want to write generic class for server requests this post is for You.

I preffer code examples over the words and funny images, so You will not spend a lot of time here.

Let's define our allowed endpoints and constraints:

const enum Endpoints {
    users = '/api/users', // GET | POST       
    notes = '/api/notes', //  POST | DELETE   
    entitlements = '/api/entitlements' // GET 
}

Let's assume that backend developer allowed You to make:

GET | POST requests for users
POST | DELETE requests for notes
GET requests for entitlements

Now, we can also define allowed methods for each endpoint :


interface HandleUsers {
    get<T>(url: Endpoints.users): Promise<T>;
    post(url: Endpoints.users): Promise<Response>;
}

interface HandleNotes {
    post(url: Endpoints.notes): Promise<Response>;
    delete(url: Endpoints.notes): Promise<Response>;
}

interface HandleEntitlements {
    get<T>(url: Endpoints.entitlements): Promise<T>;
}

Now, we can define our main class:

class Api {
    get = <T = void>(url: Endpoints): Promise<T> => fetch(url)
    post = (url: Endpoints) => fetch(url, { method: 'POST' })
    delete = (url: Endpoints) => fetch(url, { method: 'DELETE' })
}

For now, class Api does not have any constraints.
So let's define them:


// Just helper
type RequiredGeneric<T> = T extends void
    ? { __TYPE__ERROR__: 'Please provide generic parameter' }
    : T

interface HandleHttp {
    <T extends void>(): RequiredGeneric<T>
    <T extends Endpoints.users>(): HandleUsers;
    <T extends Endpoints.notes>(): HandleNotes;
    <T extends Endpoints.entitlements>(): HandleEntitlements;
}

As You see, HandleHttp is just overloading for function. Nothing special except the first line. I will come back to it later.

We have class Api and overloadings for function. How we can combine them? Very simple - we will just create a function which returns instance of Api class.

const handleHttp: HandleHttp = <_ extends Endpoints>() => new Api();

Take a look on generic parameter of httpHandler and HandleHttp interface, there is a relation between them.

Let's test our result:

const request1 = handleHttp<Endpoints.notes>() // only delete and post methods are allowed
const request2 = handleHttp<Endpoints.users>() // only get and post methods are allowed
const request3 = handleHttp<Endpoints.entitlements>() // only get method is allowed

Wait, what if I forgot to set generic parameter for handleHttp?
Trust me, this is not a problem :) Just hover the mouse on request. Now You, why I used RequiredGeneric

const request = handleHttp() // 'Please provide generic parameter'

You will not able to call any method without generic parameter.
P.S. I believe I used here typestate pattern.

It is the end folks)