Lås upp avancerade abstraktioner: En djupdykning i TypeScripts Higher-Kinded Types

Emulering av Higher-Kinded Types i TypeScript

Eftersom TypeScript saknar en inbyggd syntax för HKT har communityt utvecklat flera kodningsstrategier. Den mest utbredda och beprövade metoden involverar en kombination av interfaces, typuppslagningar och module augmentation. Detta är den teknik som är känd från biblioteket fp-ts.

URI- och typuppslagningsmetoden

Denna metod delas upp i tre nyckelkomponenter:

1. Kind-typen: Ett generiskt "bärar"-interface för att representera HKT-strukturen.
2. URI:er: Unika strängliteraler för att identifiera varje typkonstruktor.
3. En URI-till-Typ-mappning: Ett interface som kopplar sträng-URI:erna till deras faktiska typkonstruktordefinitioner.

Låt oss bygga det steg för steg.

Steg 1: `Kind`-interfacet

Först definierar vi ett bas-interface som alla våra emulerade HKT:er kommer att följa. Detta interface fungerar som ett kontrakt.

            export interface HKT<URI, A> {
  readonly _URI: URI;
  readonly _A: A;
}

            

              
                Copy
              
            
          

Låt oss dissekera detta:

Ibland ser man detta skrivet som Kind. Namngivningen är inte kritisk, men strukturen är det.

Steg 2: URI-till-Typ-mappningen

Därefter behöver vi ett centralt register för att tala om för TypeScript vilken konkret typ en given URI motsvarar. Vi uppnår detta med ett interface som vi kan utöka med hjälp av module augmentation.

            export interface URItoKind<A> {
  // This will be populated by different modules
}

            

              
                Copy
              
            
          

Detta interface lämnas avsiktligt tomt. Det fungerar som en "krok". Varje modul som vill definiera en higher-kinded type kommer att lägga till en post i det.

Steg 3: Definiera en `Kind`-hjälptyp

Nu skapar vi en verktygstyp som kan lösa upp en URI och en typparameter tillbaka till en konkret typ.

            export type Kind<URI extends keyof URItoKind<any>, A> = URItoKind<A>[URI];

            

              
                Copy
              
            
          

Steg 4: Registrera en typ (t.ex. `Array`)

För att göra vårt system medvetet om den inbyggda Array-typen måste vi registrera den. Vi gör detta med hjälp av module augmentation.

            // I en fil som `Array.ts`

// Först, deklarera en unik URI för Array-typkonstruktorn
export const URI = 'Array';
declare module './hkt' { // Förutsätter att våra HKT-definitioner finns i `hkt.ts`
  interface URItoKind<A> {
    readonly [URI]: Array<A>;
  }
}

            

              
                Copy
              
            
          

Låt oss bryta ner vad som just hände:

Nu fungerar vår Kind-typ för Array! Typen Kind<'Array', number> kommer att lösas upp av TypeScript som URItoKind['Array'], vilket, tack vare vår module augmentation, är Array. Vi har framgångsrikt kodat Array som en HKT.

Sätta ihop allt: En generisk `map`-funktion

Med vår HKT-kodning på plats kan vi äntligen skriva den abstrakta map-funktion vi drömde om. Själva funktionen kommer inte att vara generisk; istället kommer vi att definiera ett generiskt interface kallat Functor som beskriver alla typkonstruktorer som kan mappas över.

            // I `Functor.ts`
import { HKT, Kind, URItoKind } from './hkt';

export interface Functor<F extends keyof URItoKind<any>> {
  readonly URI: F;
  readonly map: <A, B>(fa: Kind<F, A>, f: (a: A) => B) => Kind<F, B>;
}

            

              
                Copy
              
            
          

Detta Functor-interface är i sig generiskt. Det tar en typparameter, F, som är begränsad till att vara en av våra registrerade URI:er. Det har två medlemmar:

• URI: Funktorns URI (t.ex. 'Array').
• map: En generisk metod. Notera dess signatur: den tar en `Kind` och en funktion, och returnerar en `Kind`. Detta är vår abstrakta map!

Nu kan vi tillhandahålla en konkret instans av detta interface för Array.

            // I `Array.ts` igen

import { Functor } from './Functor';

// ... föregående Array HKT-setup

export const array: Functor<typeof URI> = {
  URI: URI,
  map: <A, B>(fa: Array<A>, f: (a: A) => B): Array<B> => fa.map(f)
};

            

              
                Copy
              
            
          

Här skapar vi ett objekt array som implementerar Functor<'Array'>. map-implementationen är helt enkelt en omslutning (wrapper) runt den inbyggda metoden Array.prototype.map.

Slutligen kan vi skriva en funktion som använder denna abstraktion:

            function doSomethingWithFunctor<F extends keyof URItoKind<any>>(
  functor: Functor<F>
) {
  return <A, B>(fa: Kind<F, A>, f: (a: A) => B): Kind<F, B> => {
    return functor.map(fa, f);
  };
}

// Användning:
const numbers = [1, 2, 3];
const double = (n: number) => n * 2;

// Vi skickar in array-instansen för att få en specialiserad funktion
const mapForArray = doSomethingWithFunctor(array);
const doubledNumbers = mapForArray(numbers, double); // [2, 4, 6]

console.log(doubledNumbers); // Typen härleds korrekt som number[]

            

              
                Copy
              
            
          

Det fungerar! Vi har skapat en funktion doSomethingWithFunctor som är generisk över behållartypen F. Den vet inte om den arbetar med en Array, en Promise, eller en Option. Den vet bara att den har en Functor-instans för den behållaren, vilket garanterar att det finns en map-metod med rätt signatur.

Praktiska tillämpningar: Bygga funktionella abstraktioner

Functor är bara början. Den primära motivationen för HKT är att bygga en rik hierarki av typklasser (interfaces) som fångar vanliga beräkningsmönster. Låt oss titta på två till som är väsentliga: Applikativa Funktorer och Monader.

Applikativa Funktorer: Applicera funktioner i ett sammanhang

En Funktor låter dig applicera en vanlig funktion på ett värde inuti ett sammanhang (t.ex. `map(värdeIContext, vanligFunktion)`). En Applikativ Funktor (eller bara Applikativ) tar detta ett steg längre: den låter dig applicera en funktion som också finns inuti ett sammanhang på ett värde i ett sammanhang.

Applikativ-typklassen utökar Funktor och lägger till två nya metoder:

1. of (även känd som `pure`): Tar ett vanligt värde och lyfter in det i sammanhanget. För Array skulle of(x) vara [x]. För Promise skulle of(x) vara Promise.resolve(x).
2. ap: Tar en behållare som innehåller en funktion `(a: A) => B` och en behållare som innehåller ett värde `A`, och returnerar en behållare som innehåller ett värde `B`.

            import { Functor } from './Functor';
import { Kind, URItoKind } from './hkt';

export interface Applicative<F extends keyof URItoKind<any>> extends Functor<F> {
  readonly of: <A>(a: A) => Kind<F, A>;
  readonly ap: <A, B>(fab: Kind<F, (a: A) => B>, fa: Kind<F, A>) => Kind<F, B>;
}

            

              
                Copy
              
            
          

När är detta användbart? Föreställ dig att du har två värden i ett sammanhang, och du vill kombinera dem med en funktion som tar två argument. Till exempel, du har två formulärfält som returnerar en `Option` (där `Option` är en typ som kan vara `Some` eller `None`).

            // Anta att vi har en Option-typ och dess Applikativ-instans

const name: Option<string> = some('Alice');
const age: Option<number> = some(30);

const createUser = (name: string) => (age: number) => ({ name, age });

// Hur applicerar vi createUser på name och age?

// 1. Lyft den curried funktionen in i Option-sammanhanget
const curriedUserInOption = option.of(createUser);
// curriedUserInOption is of type Option<(name: string) => (age: number) => User>

// 2. `map` fungerar inte direkt. Vi behöver `ap`!
const userBuilderInOption = option.ap(option.map(curriedUserInOption, f => f), name);
// Detta är klumpigt. Ett bättre sätt:
const userBuilderInOption2 = option.map(name, createUser);
// userBuilderInOption2 is of type Option<(age: number) => User>

// 3. Applicera funktionen-i-ett-sammanhang på åldern-i-ett-sammanhang
const userInOption = option.ap(userBuilderInOption2, age);
// userInOption is Some({ name: 'Alice', age: 30 })

            

              
                Copy
              
            
          

Detta mönster är otroligt kraftfullt för saker som formulärvalidering, där flera oberoende valideringsfunktioner returnerar ett resultat i ett sammanhang (som `Either`), och du vill kombinera alla resultat. Applikativer låter dig aggregera fel från alla valideringar, medan nästa abstraktion, Monader, skulle kortsluta vid det första felet.

Monader: Sekvensering av operationer i ett sammanhang

Monaden är kanske den mest kända och ofta missförstådda funktionella abstraktionen. En Monad används för att sekvensera operationer där varje steg beror på resultatet från det föregående, och varje steg returnerar ett värde omslutet av samma sammanhang.

Monad-typklassen utökar Applikativ och lägger till en avgörande metod: chain (även känd som `flatMap` eller `bind`).

            import { Applicative } from './Applicative';
import { Kind, URItoKind } from './hkt';

export interface Monad<M extends keyof URItoKind<any>> extends Applicative<M> {
  readonly chain: <A, B>(fa: Kind<M, A>, f: (a: A) => Kind<M, B>) => Kind<M, B>;
}

            

              
                Copy
              
            
          

Den avgörande skillnaden mellan `map` och `chain` är funktionen de accepterar:

• map tar en funktion (a: A) => B. Den applicerar en "vanlig" funktion.
• chain tar en funktion (a: A) => Kind. Den applicerar en funktion som själv returnerar ett värde i det monadiska sammanhanget.

chain är det som hindrar dig från att sluta med nästlade sammanhang som Promise> eller Option>. Den "plattar" automatiskt ut resultatet.

Ett klassiskt exempel: Promises

Du har troligtvis använt Monader utan att inse det. Promise.prototype.then fungerar som en monadisk chain (när callback-funktionen returnerar en annan Promise).

            interface User { id: number; name: string; }
interface Post { userId: number; content: string; }

function getUser(id: number): Promise<User> {
  return Promise.resolve({ id, name: 'Bob' });
}

function getLatestPost(user: User): Promise<Post> {
  return Promise.resolve({ userId: user.id, content: 'Hello HKTs!' });
}

// Utan `chain` (`then`) skulle du få en nästlad Promise:
const nestedPromise: Promise<Promise<Post>> = getUser(1).then(user => {
  // Denna `then` fungerar som `map` här
  return getLatestPost(user); // returnerar en Promise, vilket skapar Promise<Promise<...>>
});

// Med monadisk `chain` (`then` när den plattar ut), är strukturen ren:
const postPromise: Promise<Post> = getUser(1).then(user => {
  // `then` ser att vi returnerade en Promise och plattar automatiskt ut den.
  return getLatestPost(user);
});

            

              
                Copy
              
            
          

Att använda ett HKT-baserat Monad-interface låter dig skriva funktioner som är generiska över alla sekventiella, sammanhangsmedvetna beräkningar, oavsett om det är asynkrona operationer (Promise), operationer som kan misslyckas (Either, Option), eller beräkningar med delat tillstånd (State).

Framtiden för HKT i TypeScript

De emuleringstekniker vi har diskuterat är kraftfulla men kommer med kompromisser. De introducerar en betydande mängd "boilerplate" (standardkod) och en brant inlärningskurva. Felmeddelandena från TypeScript-kompilatorn kan vara kryptiska när något går fel med kodningen.

Så, hur är det med inbyggt stöd? Förfrågan om Higher-Kinded Types (eller någon mekanism för att uppnå samma mål) är en av de äldsta och mest diskuterade frågorna i TypeScripts GitHub-arkiv. TypeScript-teamet är medvetet om efterfrågan, men att implementera HKT medför betydande utmaningar:

1. Syntaktisk komplexitet: Att hitta en ren, intuitiv syntax som passar bra med det befintliga typsystemet är svårt. Förslag som type F eller F :: * -> * har diskuterats, men var och en har sina för- och nackdelar.
2. Härledningsutmaningar: Typhärledning, en av TypeScripts största styrkor, blir exponentiellt mer komplex med HKT. Att säkerställa att härledningen fungerar tillförlitligt och med god prestanda är ett stort hinder.
3. Anpassning till JavaScript: TypeScript strävar efter att anpassa sig till JavaScripts körtidsverklighet. HKT är en ren kompileringstids-, typnivå-konstruktion, vilket kan skapa en konceptuell klyfta mellan typsystemet och den underliggande körtiden.

Även om inbyggt stöd kanske inte ligger i den närmaste framtiden, bevisar den pågående diskussionen och framgången för bibliotek som fp-ts, Effect och ts-toolbelt att koncepten är värdefulla och tillämpliga i en TypeScript-kontext. Dessa bibliotek tillhandahåller robusta, färdigbyggda HKT-kodningar och ett rikt ekosystem av funktionella abstraktioner, vilket besparar dig från att skriva standardkoden själv.

Slutsats: En ny nivå av abstraktion

Higher-Kinded Types representerar ett betydande språng i abstraktion på typnivå. De låter oss gå bortom att vara generiska över värdena i våra datastrukturer till att vara generiska över själva strukturen. Genom att abstrahera över behållare som Array, Promise, Option, och Either kan vi skriva universella funktioner och interfaces – som Funktor, Applikativ och Monad – som fångar grundläggande beräkningsmönster.

Även om TypeScripts brist på inbyggt stöd tvingar oss att förlita oss på komplexa kodningar, kan fördelarna vara enorma för biblioteksförfattare och applikationsutvecklare som arbetar med stora, komplexa system. Att förstå HKT gör att du kan:

• Skriva mer återanvändbar kod: Definiera logik som fungerar för alla datastrukturer som följer ett specifikt interface (t.ex. Functor).
• Förbättra typsäkerheten: Upprätthålla kontrakt för hur datastrukturer ska bete sig på typnivå, vilket förhindrar hela klasser av buggar.
• Anamma funktionella mönster: Utnyttja kraftfulla, beprövade mönster från den funktionella programmeringsvärlden för att hantera sidoeffekter, hantera fel och skriva deklarativ, komponerbar kod.

Resan in i HKT är utmanande, men det är en givande resa som fördjupar din förståelse för TypeScripts typsystem och öppnar upp nya möjligheter för att skriva ren, robust och elegant kod. Om du vill ta dina TypeScript-färdigheter till nästa nivå är att utforska bibliotek som fp-ts och bygga dina egna enkla HKT-baserade abstraktioner en utmärkt startpunkt.