Typescript-feil: Egenskapen brukes før den er tildelt

Typescript viser [ts] Egenskapen 'logger' brukes før den er tilordnet i VSCode. Feilen oppstår i koden nedenfor på this.logger.logInfo(Viktig, .... Jeg setter veldig tydelig denne egenskapen på den andre linjen i konstruktøren, så...?

Hvis jeg brukte self-variabelen vist i koden (self.logger.logInfo...), forsvinner TS-feilen, men dette burde ikke være nødvendig.

Takk for at du deler din ekspertise :-)

// app/data/mongo/_base.data.mongo.ts 

import { MongoClient, ObjectId } from 'mongodb';
import { IBaseModel } from '../../model/_base.model';
import { Logger, Important, NotImportant } from '../../util/logger';

export default class BaseData {

    constructor(params: any) {
        this.collectionName = params.collectionName;
        this.logger = new Logger(this.collectionName);
        if (this.db) {
            this.collection = this.db.getCollection(this.collectionName);
        } else {
            BaseData.userId = params.user.id;
            BaseData.userHandle = params.user.handle;
            this.dbServer = params.dbServer;
            this.dbPort = params.dbPort || '27017';
            this.dbName = params.dbName;
            const self = this; // This is a Typescript BUG!
            (async () => {
                const url = `mongodb://${this.dbServer}:${this.dbPort}`;
                this.db = await MongoClient.connect(url, { "useNewUrlParser": true });
                this.collection = this.db.collection(this.collectionName);
                this.logger.logInfo(Important, 'contructor', `MongoDb connection (${url}) success!`);
            })();
        }
    }

    static userId: string;
    static userHandle: string;

    protected logger: Logger;
    protected collectionName: string = '';
    protected client: any;
    protected collection: any;
    protected db: any;
    protected dbServer: string = '';
    protected dbPort: string = '';
    protected dbName: string = '';

Svar #1

Her er litt selvstendig kode som gjenskaper problemet:

// Turn on --strictNullChecks and --strictPropertyInitialization
class Foo {
    prop: string;
    constructor() {
        this.prop = "assigned";
        (async () => {
            this.prop; // error, used before assigned
        })();
    }
}

Se på lekeplassen (husk å slå på --strictNullChecks og --strictPropertyInitialization kompilatorvalg).

Dette kan godt være en designbegrensning i TypeScript, om ikke en fullverdig feil. Faktum er at automatisk kontrollflytanalyse er vanskelig å gjøre «riktig». Siden det generelt er umulig for kompilatoren å finne ut nøyaktig hvilke tilstander som er mulige for hver variabel på hvert punkt i et program, må den bruke heuristikker, som til sammen ofte resulterer både i falske negativer (ufangede feil) og falske positiver (fangede ikke-feil). Dette virker som et falskt positivt resultat for meg, siden den asynkrone funksjonen definitivt blir kalt etter at this.prop er satt. Et lignende problem har blitt reist og håndtert tidligere, med synkrone umiddelbart-innkalte funksjonsuttrykk.

Jeg tror at noen som har mer kunnskap om detaljene i hvordan TypeScript utfører kontrollflytanalyse, ville være nødvendig for å kunne uttale seg autoritativt her, men jeg antar at denne spesifikke situasjonen rett og slett ikke har blitt forutsett eller møtt ofte nok til å håndteres. Hvis du mener du har et overbevisende bruksområde for dette, kan det være lurt å opprette en sak på GitHub, forutsatt at ingen gir et mer tilfredsstillende svar på dette spørsmålet.

I mellomtiden, hvis du har en løsning, slik som å tildele const self=this og deretter få tilgang til self.prop, eller tilsvarende tilgang til (this as this).prop, så antar jeg at du bør bruke den. Og det finnes alltid slegga av alle løsninger, kommentaren //@ts-ignore:

class Foo {
  prop: string;
  constructor() {
    this.prop = "assigned";
    (async () => {
      // @ts-ignore: this.prop is really assigned before being used
      this.prop;
    })();
  }
}

Å ja vel, beklager at jeg ikke har bedre nyheter. Håper det hjelper uansett. Lykke til!

Relaterte artikler