Recent articles About

Compiling enterprise

Ivan Koshelev blog on software development

Articles for tags 'types' Pragmatic uses of Typescript type system 03 Tag hierarchies via Template Literal Types [2021 May 09] Typescript, types, tagged union types, template literal types, hierarchy, polymorphism Features described in the articles require Typescript 4.3, which is in beta at the time of writing.

Tagged union types are a great part of Typescript, indispensible when working with groups of related data types, the kind we are likely to receive in JSON form from some API. They allow us to generalize groups of those types and strong-type functions that can operate on any member of the group.


const catTag = `cat` as const;
const dogTag = `dog` as const;

type CatRecord = {
    type: typeof catTag,
    name: string,
    huntsMice: boolean,
}

type DogRecord = {
    type: typeof dogTag,
    name: string,
    lovesFetch: boolean
}

type AnimalRecord = CatRecord | DogRecord;

declare const cat: CatRecord
let a: AnimalRecord = cat; // all good :-)
TS playground

This approach works fine in many situations, but its limits quickly become visible when we try modeling hierarchies of data.


const vanTag = `van` as const;
const ambulanceTag = `ambulance` as const;
type FuelType = 'gasoline' | 'diesel' | 'electric';

type VanRecord = {
    type: typeof vanTag,
    fuelType: FuelType
}

type AmbulanceRecord = Omit<VanRecord, 'type'> & {
    type: typeof ambulanceTag,
    medicalEquipment: string[]
}

type FuelStation = {
    availableFuels: FuelType[]
}

function canRefuel(station: FuelStation, van: VanRecord) {
    return station.availableFuels.some(x => x === van.fuelType);
}

declare const station: FuelStation;
declare const van: VanRecord;
declare const ambulance: AmbulanceRecord;

canRefuel(station, van); // fine
canRefuel(station, ambulance); // error!
TS playground

So how can we both have tagged types and make sure that 'canRefuel' function accepts any type derived from 'Van'?

continue reading
Advanced uses of Typescript type system 01 From mapped types to compile-time type construction [2019 July 21] Typescript, types, type mapping This article continues exploration of typescript type system applications. Previous articles on pragmatic uses of ad-hoc typing and mapped types showcased type system usages for application developers. This one will go a bit deeper, and is more useful for library developers. Make sure you fully understand concepts explained previously.

Generic classes in C# and Java can be thought of as class templates, which let us use placeholders instead of certain types. What they don't allow is having generic property names. Typescript does not have such limitation and easily lets us do that:

export type MakeProp<TKey extends string , TType> = {
  [key in TKey]: TType
}

// MakeProp<'foo', number>
type equivalent1 = {
    foo: number;
}
TS playground

This does not look so impressive, after all, we could have written this type by hand just as easily. What we should know, however, is that we have passed they type-key barrier ( not a real term :-) ) - we managed to make type into a key and create an object shape using only other types. This means, we can use our 'MakeProp' type within other generic types in Typescript. With mapped and conditional types, this means we can construct much more complex types with our mappings.

continue reading
Pragmatic uses of Typescript type system 02 Mapped types [2019 May 15] Typescript, types, type mapping

If you keep track of TypeScript innovations, you've probably used a Mapped Type like Partial, and maybe even pressed “Go to definition” to see, how it is defined under the hood.

type Partial<T> = {
    [P in keyof T]?: T[P];
}

Sadly, while many people are using predefined Mapped Types, few have adapted writing their own to utilize the full power of Typescript. Even fewer still realize the full extent of their power in types like the following:

// Readonly that is applied recursively 
// to properties which are objects, instead of just first level
type ReadonlyDeep<TType> = {
    readonly [key in keyof TType]: TType extends Object 
                                        ? ReadonlyDeep<TType[key]> 
                                        : TType[key];
}

let t = {b: 1, c: {d:2}}

let readonly: Readonly<typeof t> = t;
readonly.c.d = 5; // :-( no error

let readonlyDeep: ReadonlyDeep<typeof t> = t;
readonlyDeep.c.d = 5; // :-) error!


// A way to get keoyf only for certain types of keys
type KeyofMethods<TType> = ({
    [key in keyof TType]: TType[key] extends Function 
                            ? key // notice, use of key instead of TType[key] 
                            : never
})[keyof TType];

class FooBar {
    a: number = 0;
    c(){ return 0;};
    d(){ return 0;};
}

type km = KeyofMethods<FooBar>; //"c"|"d" 


// A way to prohibit access to anything that is not a function,
// to enforce method usage in part of code, while having relaxed rules elsewhere
type MethodsOf<TType> = Pick<TType, KeyofMethods<TType>>

const m = <MethodsOf<FooBar>> new FooBar();
let c: number = m.c(); // fine
let a = m.a;    //error!
TS playground

Lets explore the practical application and peek into still more fantastic possibilities.

continue reading
Pragmatic uses of Typescript type system 01 My type of type [2019 February 22] Typescript, types, interfaces, duck typing

You may have heard, that TypeScripts type system has been prooven turing-complete . In layman’s terms this means you can write type definitions in such a way, that compiler will execute a simple program from just trying to compile them. A fascinating fact, but how is it useful in our daily work? It tells us, that TS type system is on a whole next level compared to what we are used to in Java and C#, and we should rethink our approach to it. In this article, we won't delve into the arcana of things like conditional types, but will concentrate on the often overlooked (especially by devs coming from the static typing world) practical uses of TS type system, that make daily life of a dev much easier.

Robert C. Martin of Clean Code fame once said, it would be nice if we could instruct compiler to use concrete types in Java only for their signature of abstractions, i.e., interfaces. Indeed, for 95% of enterprise code I work with, formal interface types serve as a technical detail, needed by the compiler only. Such case is easy to recognize: your interface has only 1 implementation (not counting testing mocks) and you don't have to ship/deploy this implementation separately (it is in the same DLL as interface, or the dll is separate, but always goes together). This is a clear sign:

  • this interface is driven by a single use case, which is fully reflected in single concrete implementation
  • only needed to teach compiler about proper dependency abstraction
  • you as a dev don't get anything out of it, worse yet, you are forced to duplicate member definitions
Ask yourself, how many interfaces in your application can be resolved by your IoC container automatically? Realizing this, I always wanted to be able to decorate my C# classes with a keyword or attribute, that would give me an automatic interface based on their concrete implementation and containing all their public members. Well, guess what we can do in TS?

class Foo {
    bar: number;
    baz() { console.log(this.bar); }
}

// An interface extends a class!
interface IFoo extends Foo { }

let foo = {} as IFoo;

let bar:number = foo.bar;
foo.baz();                  //type checks ok!

TS playground

And that is just the tip of the iceberg, real power comes in type!

continue reading
Ivan Koshelev photo

I'm passionate for anything that can be programed and automated to make life better for all of us.

Archives

  1. May 2021 (1)
  2. March 2020 (1)
  3. August 2019 (1)
  4. July 2019 (1)
  5. May 2019 (1)
  6. February 2019 (1)
  7. October 2017 (1)
  8. August 2017 (3)
  9. July 2017 (3)
  10. May 2017 (3)

Elsewhere

  1. GitHub@IKoshelev
  2. NuGet@IKoshelev
  3. LinkedIn