Dlaczego mogę uzyskać dostęp do prywatnych elementów członkowskich TypeScript, kiedy nie powinienem?

Patrzę na implementację prywatnych członków w TypeScript i wydaje mi się to trochę zagmatwane. Intellisense nie pozwala na dostęp do prywatnego członka, ale w czystym JavaScript wszystko tam jest. To sprawia, że ​​myślę, że TS nie implementuje poprawnie prywatnych członków. jakieś pomysły?

class Test{
  private member: any = "private member";
}
alert(new Test().member);

Podobnie jak w przypadku sprawdzania typu, prywatność członków jest wymuszana tylko w kompilatorze.

Właściwość prywatna jest zaimplementowana jako zwykła właściwość i kod spoza klasy nie ma do niej dostępu.

Aby coś było naprawdę prywatne wewnątrz klasy, nie może być członkiem klasy, byłaby to zmienna lokalna utworzona w zakresie funkcji wewnątrz kodu, który tworzy obiekt. Oznaczałoby to, że nie możesz uzyskać do niego dostępu jak członek klasy, tj. Używając thissłowa kluczowego.

JavaScript obsługuje zmienne prywatne.

function MyClass() {
    var myPrivateVar = 3;

    this.doSomething = function() {
        return myPrivateVar++;        
    }
}

W TypeScript byłoby to wyrażone następująco:

class MyClass {

    doSomething: () => number;

    constructor() {
        var myPrivateVar = 3;

        this.doSomething = function () {
            return myPrivateVar++;
        }
    }
}

EDYTOWAĆ

Podejście to powinno być stosowane TYLKO RZADKO, gdy jest to absolutnie konieczne. Na przykład, jeśli chcesz tymczasowo zapisać hasło w pamięci podręcznej.

Korzystanie z tego wzorca wiąże się z kosztami wydajności (nie ma znaczenia w przypadku JavaScript ani maszynopisu) i powinno być używane tylko wtedy, gdy jest to absolutnie konieczne.

Gdy wsparcie dla WeakMap stanie się szerzej dostępne, istnieje interesująca technika szczegółowo opisana w przykładzie nr 3 tutaj .

Pozwala na prywatne dane ORAZ pozwala uniknąć kosztów wydajności, jak na przykład Jason Evans, umożliwiając dostęp do danych z metod prototypowych, a nie tylko metod instancji.

Połączona strona MDN WeakMap zawiera listę obsługiwanych przeglądarek w Chrome 36, Firefox 6.0, IE 11, Opera 23 i Safari 7.1.

let _counter = new WeakMap();
let _action = new WeakMap();
class Countdown {
  constructor(counter, action) {
    _counter.set(this, counter);
    _action.set(this, action);
  }
  decrement() {
    let counter = _counter.get(this);
    if (counter < 1) return;
    counter--;
    _counter.set(this, counter);
    if (counter === 0) {
      _action.get(this)();
    }
  }
}

Ponieważ TypeScript 3.8 zostanie wydany, będziesz mógł zadeklarować pole prywatne, do którego nie można uzyskać dostępu lub nawet wykryć je poza klasą zawierającą .

class Person {
    #name: string

    constructor(name: string) {
        this.#name = name;
    }

    greet() {
        console.log(`Hello, my name is ${this.#name}!`);
    }
}

let jeremy = new Person("Jeremy Bearimy");

jeremy.#name
//     ~~~~~
// Property '#name' is not accessible outside class 'Person'
// because it has a private identifier.

Pola prywatne zaczynają się od #znaku

Należy pamiętać, że te prywatne pola będą inne niż pola oznaczone privatesłowem kluczowym

Nr ref. https://devblogs.microsoft.com/typescript/announcing-typescript-3-8-beta/

Podziękowania dla Seana Feldmana za link do oficjalnej dyskusji na ten temat - zobacz jego odpowiedź na link.

Przeczytałem dyskusję, z którą się łączył, i oto podsumowanie najważniejszych punktów:

• Sugestia: prywatne własności w konstruktorze
  • problemy: brak dostępu z funkcji prototypowych
• Sugestia: metody prywatne w konstruktorze
  • problemy: to samo, co w przypadku właściwości, dodatkowo tracisz korzyści wynikające z tworzenia funkcji raz na klasę w prototypie; zamiast tego tworzysz kopię funkcji dla każdej instancji
• Sugestia: dodaj szablon do abstrakcyjnego dostępu do właściwości i wymuś widoczność
  • problemy: duże obciążenie wydajnościowe; TypeScript jest przeznaczony dla dużych aplikacji
• Sugestia: TypeScript już opakowuje definicje konstruktora i metody prototypowej w zamknięciu; umieść tam prywatne metody i właściwości
  • problemy z zamknięciem własności prywatnych: stają się zmiennymi statycznymi; nie ma jednego na instancję
  • problemy z zamknięciem metod prywatnych: nie mają do nich dostępu thisbez jakiegoś obejścia
• Sugestia: automatycznie zmieniaj prywatne nazwy zmiennych
  • kontrargumenty: to konwencja nazewnictwa, a nie konstrukcja języka. Wymieszaj to sam
• Sugestia:@private dodaj adnotacje do metod prywatnych za pomocą minifier, które rozpoznają, że adnotacja może skutecznie zminimalizować nazwy metod
  • Brak znaczących kontrargumentów do tego

Ogólne kontrargumenty do dodania obsługi widoczności w emitowanym kodzie:

• problem polega na tym, że sam JavaScript nie ma modyfikatorów widoczności - to nie jest problem TypeScript
• w społeczności JavaScript istnieje już ustalony wzorzec: poprzedzaj prywatne właściwości i metody podkreśleniem, które mówi „postępuj na własne ryzyko”
• kiedy projektanci TypeScript powiedzieli, że prawdziwie prywatne właściwości i metody nie są „możliwe”, mieli na myśli „niemożliwe w ramach naszych ograniczeń projektowych”, a konkretnie:
  • Emitowany JS jest idiomatyczny
  • Płyta kotłowa jest minimalna
  • Brak dodatkowych kosztów w porównaniu do zwykłego JS OOP

W języku TypeScript funkcje prywatne są dostępne tylko wewnątrz klasy. Lubić

I pokaże błąd podczas próby uzyskania dostępu do członka prywatnego. Oto przykład:

Uwaga: będzie dobrze z javascriptem, a obie funkcje są dostępne na zewnątrz.

Zdaję sobie sprawę, że jest to starsza dyskusja, ale nadal może być przydatne podzielenie się moim rozwiązaniem problemu rzekomo prywatnych zmiennych i metod w TypeScript „wyciekającym” do publicznego interfejsu skompilowanej klasy JavaScript.

Dla mnie ta kwestia jest czysto kosmetyczna, tj. Chodzi o wizualny bałagan, gdy zmienna instancji jest wyświetlana w DevTools. Moją poprawką jest zgrupowanie prywatnych deklaracji razem w innej klasie, która jest następnie tworzona w klasie głównej i przypisywana do privatezmiennej (ale nadal widocznej publicznie w JS) o nazwie takiej jak __(podwójne podkreślenie).

Przykład:

class Privates {
    readonly DEFAULT_MULTIPLIER = 2;
    foo: number;
    bar: number;

    someMethod = (multiplier: number = this.DEFAULT_MULTIPLIER) => {
        return multiplier * (this.foo + this.bar);
    }

    private _class: MyClass;

    constructor(_class: MyClass) {
        this._class = _class;
    }
}

export class MyClass {
    private __: Privates = new Privates(this);

    constructor(foo: number, bar: number, baz: number) {
        // assign private property values...
        this.__.foo = foo;
        this.__.bar = bar;

        // assign public property values...
        this.baz = baz;
    }

    baz: number;

    print = () => {
        console.log(`foo=${this.__.foo}, bar=${this.__.bar}`);
        console.log(`someMethod returns ${this.__.someMethod()}`);
    }
}

let myClass = new MyClass(1, 2, 3);

Kiedy myClassinstancja jest oglądana w DevTools, zamiast widzieć wszystkich jej „prywatnych” członków wymieszanych z prawdziwie publicznymi (co może być bardzo wizualnie niechlujne w prawidłowo zrefaktorowanym prawdziwym kodzie), zobaczysz je zgrupowane w zwiniętej __właściwości:

Oto podejście wielokrotnego użytku do dodawania odpowiednich właściwości prywatnych:

/**
 * Implements proper private properties.
 */
export class Private<K extends object, V> {

    private propMap = new WeakMap<K, V>();

    get(obj: K): V {
        return this.propMap.get(obj)!;
    }

    set(obj: K, val: V) {
        this.propMap.set(obj, val);
    }
}

Załóżmy, że masz Clientgdzieś zajęcia, które wymagają dwóch prywatnych właściwości:

• prop1: string
• prop2: number

Poniżej opisano, jak to wdrażasz:

// our private properties:
interface ClientPrivate {
    prop1: string;
    prop2: number;
}

// private properties for all Client instances:
const pp = new Private<Client, ClientPrivate>();

class Client {
    constructor() {
        pp.set(this, {
            prop1: 'hello',
            prop2: 123
        });
    }

    someMethod() {
        const privateProps = pp.get(this);

        const prop1 = privateProps.prop1;
        const prop2 = privateProps.prop2;
    }
}

A jeśli wszystko, czego potrzebujesz, to jedna własność prywatna, to staje się jeszcze prostsze, ponieważ ClientPrivatew takim przypadku nie musisz jej definiować .

Warto zauważyć, że w przeważającej części class Privatepo prostu oferuje ładnie czytelną sygnaturę, podczas gdy bezpośrednie użycie WeakMapnie.