Por que posso acessar membros privados do TypeScript quando não deveria?

Estou olhando para a implementação de membros privados no TypeScript e acho um pouco confuso. O Intellisense não permite acessar um membro privado, mas em JavaScript puro, está tudo lá. Isso me faz pensar que o TS não implementa membros privados corretamente. Alguma ideia?

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

Assim como com a verificação de tipo, a privacidade dos membros só é imposta no compilador.

Uma propriedade privada é implementada como uma propriedade regular e o código fora da classe não tem permissão para acessá-la.

Para tornar algo realmente privado dentro da classe, não pode ser um membro da classe, seria uma variável local criada dentro de um escopo de função dentro do código que cria o objeto. Isso significaria que você não pode acessá-lo como um membro da classe, ou seja, usando a thispalavra - chave.

JavaScript oferece suporte a variáveis ​​privadas.

function MyClass() {
    var myPrivateVar = 3;

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

No TypeScript, isso seria expresso assim:

class MyClass {

    doSomething: () => number;

    constructor() {
        var myPrivateVar = 3;

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

EDITAR

Essa abordagem só deve ser usada PARCIALMENTE onde for absolutamente necessária. Por exemplo, se você precisar armazenar uma senha temporariamente.

Existem custos de desempenho para usar este padrão (irrelevante de Javascript ou Typescript) e só deve ser usado quando for absolutamente necessário.

Uma vez que o suporte para WeakMap esteja mais amplamente disponível, há uma técnica interessante detalhada no exemplo # 3 aqui .

Ele permite dados privados E evita os custos de desempenho do exemplo de Jason Evans, permitindo que os dados sejam acessíveis a partir de métodos de protótipo em vez de apenas métodos de instância.

A página MDN WeakMap vinculada lista o suporte do navegador no Chrome 36, Firefox 6.0, IE 11, Opera 23 e 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)();
    }
  }
}

Como o TypeScript 3.8 será lançado, você poderá declarar um campo privado que não pode ser acessado ou mesmo detectado fora da classe que o contém .

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.

Os campos privados começam com #caracteres

Observe que esses campos privados serão diferentes dos campos marcados com a privatepalavra - chave

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

Agradecimentos a Sean Feldman pelo link para a discussão oficial sobre este assunto - veja sua resposta no link.

Li a discussão à qual ele vinculou e aqui está um resumo dos pontos-chave:

• Sugestão: propriedades privadas no construtor
  • problemas: não consigo acessar a partir de funções de protótipo
• Sugestão: métodos privados no construtor
  • problemas: o mesmo que com as propriedades, mais você perde o benefício de desempenho de criar uma função uma vez por classe no protótipo; em vez disso, você cria uma cópia da função para cada instância
• Sugestão: adicione clichê para abstrair o acesso à propriedade e reforçar a visibilidade
  • problemas: sobrecarga de desempenho importante; TypeScript é projetado para grandes aplicativos
• Sugestão: o TypeScript já envolve as definições do construtor e do método do protótipo em um encerramento; coloque métodos privados e propriedades lá
  • problemas em colocar propriedades privadas nesse fechamento: eles se tornam variáveis ​​estáticas; não há um por instância
  • problemas em colocar métodos privados nesse encerramento: eles não têm acesso thissem algum tipo de solução alternativa
• Sugestão: mutilar automaticamente os nomes das variáveis ​​privadas
  • contra-argumentos: isso é uma convenção de nomenclatura, não uma construção de linguagem. Destrua você mesmo
• Sugestão: anote métodos privados com @privateminificadores so que reconheçam que a anotação pode reduzir efetivamente os nomes dos métodos
  • Sem contra-argumentos significativos para este

Contra-argumentos gerais para adicionar suporte de visibilidade no código emitido:

• o problema é que o próprio JavaScript não tem modificadores de visibilidade - este não é o problema do TypeScript
• já existe um padrão estabelecido na comunidade JavaScript: prefixe propriedades e métodos privados com um sublinhado, que diz "proceda por sua própria conta e risco"
• quando os designers do TypeScript disseram que as propriedades e métodos verdadeiramente privados não são "possíveis", eles queriam dizer "não é possível sob nossas restrições de design", especificamente:
  • O JS emitido é idiomático
  • Boilerplate é mínimo
  • Sem sobrecarga adicional em comparação com JS OOP normal

No TypeScript, as funções privadas são acessíveis apenas dentro da classe. Gostar

E mostrará um erro quando você tentar acessar um membro privado. Aqui está o exemplo:

Nota: Vai funcionar bem com javascript e ambas as funções são acessíveis externamente.

Sei que esta é uma discussão mais antiga, mas ainda pode ser útil compartilhar minha solução para o problema das variáveis ​​e métodos supostamente privados em um TypeScript "vazando" para a interface pública da classe JavaScript compilada.

Para mim, esse problema é puramente cosmético, ou seja, é tudo sobre a desordem visual quando uma variável de instância é exibida no DevTools. Minha correção é agrupar declarações privadas dentro de outra classe que é então instanciada na classe principal e atribuída a uma privatevariável (mas ainda visível publicamente em JS) com um nome como __(sublinhado duplo).

Exemplo:

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);

Quando a myClassinstância é visualizada no DevTools, em vez de ver todos os seus membros "privados" misturados com os realmente públicos (o que pode ficar muito confuso visualmente em código da vida real devidamente refatorado), você os vê agrupados ordenadamente dentro da __propriedade recolhida :

Esta é uma abordagem reutilizável para adicionar propriedades privadas adequadas:

/**
 * 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);
    }
}

Digamos que você tenha uma classe em Clientalgum lugar que precise de duas propriedades privadas:

• prop1: string
• prop2: number

Abaixo está como você o implementa:

// 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;
    }
}

E se você só precisa de uma única propriedade privada, fica ainda mais simples, porque você não precisaria definir nenhuma ClientPrivatenesse caso.

Vale a pena notar que, na maioria das vezes, a classe Privateoferece apenas uma assinatura bem legível, enquanto o uso direto de WeakMapnão.