detta - Ignorera vissa TypeScript-kompileringsfel?

Jag undrar om det finns ett sätt att ignorera vissa TypeScript-fel vid kompilering?

Jag har i princip samma problem som de flesta med stora projekt har när det gäller att använda this-nyckelordet, och jag vill inte lägga alla mina klassers metoder i konstruktorn.

Så jag har ett exempel som detta:

TypeScript-exempel

Vilket verkar skapa helt giltig JS och låter mig komma runt problemet med nyckelordet this, men som du kan se i exemplet säger typescript-kompilatorn att jag inte kan kompilera den koden eftersom nyckelordet this inte är giltigt inom det scopet. Men jag förstår inte varför det är ett fel eftersom det producerar okej kod.

Så finns det ett sätt att få den att ignorera vissa fel? Jag är säker på att det med tiden kommer att finnas ett bra sätt att hantera this-nyckelordet, men för tillfället tycker jag att det är ganska illa.

== Redigera ==

(Läs inte om du inte bryr dig om sammanhanget för denna fråga och delvis klagomål)

Bara för att lägga till lite sammanhang till allt detta för att visa att jag inte bara är någon galning (jag är säker på att många av er fortfarande kommer att tycka det) och att jag har några goda skäl till varför jag vill kunna tillåta att dessa fel passerar.

Här är några tidigare frågor jag har ställt som framhäver några stora problem (enligt mig) med TypeScripts nuvarande denna implementering.

Att använda lawnchair med Typescript

Problem med barns scope av detta i Typescript

https://typescript.codeplex.com/discussions/429350 (Och några kommentarer jag gör längst ner)

Det underliggande problemet jag har är att jag behöver garantera att all logik finns inom ett konsekvent scope, jag behöver kunna komma åt saker inom knockout, jQuery etc. och den lokala instansen av en klass. Jag brukade göra detta med var self=this; inom klassdeklarationen i JavaScript och det fungerade utmärkt. Som nämnts i några av dessa tidigare frågor kan jag inte göra det nu, så det enda sättet jag kan garantera scopet är att använda lambda-metoder, och det enda sättet jag kan definiera en sådan som en metod inom en klass är inom konstruktorn, och den här delen är STARKT beroende av personlig preferens, men jag tycker det är fruktansvärt att folk verkar tro att det är rekommenderat mönster att använda den syntaxen och inte bara en tillfällig lösning.

Jag vet att TypeScript är i alfafasen och mycket kommer att förändras, och jag HOPPAS så mycket att vi får ett trevligare sätt att hantera detta men för närvarande gör jag antingen allt till en stor röra bara för att få TypeScript att fungera (och detta är inom hundratals filer som jag migrerar över till TypeScript) eller så tar jag bara beslutet att jag vet bättre än kompilatorn i det här fallet (VÄLDIGT FARLIGT VET JAG) så att jag kan hålla min kod snygg och förhoppningsvis, när ett bättre mönster kommer för att hantera detta, kan jag migrera det då.

Bara som en sidonotering vet jag att många människor älskar att TypeScript omfamnar och försöker hålla sig så nära de nya JavaScript-funktionerna och den kända syntaxen som möjligt, vilket är fantastiskt, men TypeScript ÄR INTE nästa version av JavaScript, så jag ser inget problem med att lägga till lite syntaktiskt socker i språket eftersom de som vill använda den senaste och bästa officiella JavaScript-implementationen fortfarande kan göra det.

Svar #1

Författarens specifika problem med this verkar vara löst, men frågan ställs om att ignorera fel, och för dem som hamnar här och letar efter hur man ignorerar fel:

Om det inte är möjligt att ordentligt åtgärda felet eller använda mer ordentliga lösningar som redan föreslagits här, finns det från och med TypeScript 2.6 (släppt den 31 oktober 2017) nu ett sätt att ignorera alla fel från en specifik rad genom att använda // @ts-ignore-kommentarer före målraden.

Den nämnda dokumentationen är tillräckligt kortfattad, men för att sammanfatta:

// @ts-ignore
const s : string = false

inaktiverar felrapportering för den här raden.

Detta bör dock endast användas som en sista utväg när det är mycket mer besvärligt att åtgärda felet eller använda hacks som (x as any) än att förlora all typkontroll för en rad.

När det gäller att specificera vissa fel diskuteras det nuvarande (mellan 2018) tillståndet här, i Design Meeting Notes (16/2/2018) och vidare kommentarer, vilket i princip är

"ingen slutsats ännu"

och starkt motstånd mot att införa denna finjustering.

Svar #2

Jag tror att din fråga som den är formulerad är ett XY-problem. Det du egentligen vill veta är hur kan jag säkerställa att några av mina klassmetoder garanterat har ett korrekt this-sammanhang?

För det problemet skulle jag föreslå denna lösning:

class LambdaMethods {
    constructor(private message: string) {
        this.DoSomething = this.DoSomething.bind(this);
    }

    public DoSomething() {
        alert(this.message);
    }
}

Detta har flera fördelar.

Först och främst är du tydlig med vad som pågår. De flesta programmerare kommer förmodligen inte att förstå de subtila semantiska skillnaderna mellan medlems- och metoddsyntaxen när det gäller kodgenerering.

För det andra gör det mycket tydligt, genom att titta på konstruktören, vilka metoder som kommer att ha en garanterad this-kontext. Avgörande, ur ett prestandaperspektiv, vill du inte skriva alla dina metoder på det här sättet, bara de som absolut behöver det.

Slutligen bevarar det klassens OOP-semantik. Du kommer faktiskt att kunna använda super.DoSomething från en härledd klass implementation av DoSomething.

Relaterade artiklar