Métodos e atributos privados no ES6

[fernandomoraes]

Oi, Pelo oque eu vi na web, alguns simulam com WeakMap, outros com Symbols e outros através de convenção.

Gostaria de saber de vocês, como estão tratando em à isso.

Obrigado.

[danguilherme]

Utilizo factories.

function object(param) {
  let instance = {};

  let privateProp = 1;
  function privateFn() { /* ... */ }

  instance.publicProp = privateProp + 1;
  instance.publicFn = function publicFn() {
    // ...
    privateFn();
    // ...
  }

  return instance;
}

Mas isso é à la ES5 ainda né 😂

[kazzkiq]

Essa é uma das minhas maiores decepções com a nova implementação de Classes no ES6.

Como assim eles não criaram uma forma simples de escrever métodos privados?!?!

Inclusive, esse foi um dos motivos pelo qual eu decidi adotar o TypeScript em um projeto pessoal, porque dentre outras "vantagens sintáticas", ele te permite escrever algo como:

class MinhaClasse {
    // Declarando variáveis privadas
    private minhaVariavel = 123;

    // e funções privadas
    private minhaFuncao() {
        //...
    }
}

Mas não dá pra sair enfiando TypeScript em todo projeto que você usa, e as vezes ele nem casa com o escopo de um projeto e pode acabar conflitando com outras tecnologias. Ou seja, não resolve.

Até onde eu sei, se não for usando táticas "das antigas" (ES5) como a do @danguilherme, ou alguma outra linguagem que compile pra JavaScript, como o TypeScript, não existe forma de declarar métodos e atributos privados usando a sintaxe do ES6.

Existe uma proposta de incluir private fields no futuro, e o jeito é torcer para que ela seja implementada nas próximas versões da linguagem.

[thiamsantos]

Em geral eu uso o underscore para delimitar os métodos e atributos privados faço algo como:

class MyClass {

  constructor(attr) {
    this._attr = attr;
  }

  _private() {
    // Some private method
  }

  public() {
    // Some public method
  }

}

[fernandomoraes]

@kazzkiq poiseh, tbm fiquei decepcionado com isso :/
Estou utilizando num projeto com Angular 1, e realmente me incomoda um pouco

[gsantiago]

As classes do ES6 são só açúcar sintático para funções construtoras, por isso não suportam propriedades privadas.

Uma classe como essa:

class Person {
  constructor (name, age) {
    this.name = name
    this.age = age
  }

  getAge () {
    return this.age
  }
}

Apenas cria uma função construtora com o seguinte prototype:

function Person (name, age) {
  this.name = name
  this.age = age
}

Person.prototype.getAge = function getAge () {
  return this.age
}

No final das contas, as classes do ES6 são só firulas desnecessárias que limitam a flexibilidade
que o JavaScript oferece para trabalhar com objetos. A única vantagem delas é de oferecer uma sintaxe familiar para programadores de outras linguagens OO.

O JavaScript oferece alternativas melhores para trabalhar com objetos.

[leobalter]

as classes do ES6 são só firulas desnecessárias que limitam a flexibilidade
que o JavaScript oferece para trabalhar com objetos.

Não são firulas.

Tudo começa de algum início.

@kazzkiq:

Como assim eles não criaram uma forma simples de escrever métodos privados?!?!

O JS é uma linguagem à parte, não se trata apenas de criar algo e depois ver como funciona. O processo é inverso: se cria o padrão, revisa de forma precisa e depois traz isso às runtimes para implementarem.

Classe em JS é algo novo, e no início com certeza é um syntax sugar para funções e protótipos, mas imagina o caos se não fosse?

valores privados já estão a caminho, está sendo discutido e precisa entrar da forma certa. Olha essa lista pra ver tudo que está em discussão. Veja a complexidade que isso involve até gramática de lógica de sintaxe.

Sabe o exemplo que você mencionou de TypeScript? O operador = é um problema sério ali. É preciso ter certeza se aquela operação está definindo uma propriedade ou apenas um valor. Basicamente precisa ser definido se isso vai acontecer via defineProperty ou set, e isso faz diferença.

Veja só essa confusão acontecendo com public fields (similar aos private fields) onde o Babel (até o momento que estou escrevendo) tem um erro de execução:

class Foo {
  get x() { return 42; }
  set x(y) {}
}

class Bar extends Foo {
  x = 'Hello'
}

console.log(new Bar().x); // 42

O x sai 42 por que está rolando um set e não um defineProperty ali. O certo é mudar o operador = para dois pontos (:), pois a intenção é usar defineProperty, é definir propriedade, e não dar set. Logo, a proposta está sendo mudada (provavelmente essa semana) para ficar da seguinte forma:

class Foo {
  get x() { return 42; }
  set x(y) {}
}

class Bar extends Foo {
  x: 'Hello'
}

console.log(new Bar().x); // 'Hello'

O mesmo se aplica a private fields, você define uma propriedade privada que é definida quando o this é inicializado.

Agora imagina: conforme a linguagem é padronizada, não só escrita e vamos ver no que dá, é super importante definir quando esses valores são inicializados, quando são criados. Viu ali em cima que digo que é quando o this é inicializado? É super importante ter certeza disso, se for mal definido vira caos, quem paga o preço são os desenvolvedores.

---

Agora volto à sua pergunta:

Como assim eles não criaram uma forma simples de escrever métodos privados?!?!

Nada é simples, é necessario ser muito bem definido.

Quer outra complexidade: retrocompatibilidade no JS não é só útil, é necessário. Quebrar algo pode significar quebrar a web, toda. Ou também serve dizer que os browsers simplesmente não vão implementar algo, pois eles não querem quebrar diante de meio bilhão de usuários e ver gente migrando para algo que "funcione melhor".

Pensar bem e com calma - muita paciência - é melhor que arrependimentos futuros (tipo o 'use strict' ou String.prototype.blink).

[DaviDuqueNascimento]

Particularmente não vejo segredo eu colocar métodos e atributos privados no Ecma6. Basta usar underscore para delimitar os métodos e atributos privados. As mudanças no sentido de trabalhar com objetos, que antes só era possível com algumas bibliotecas como Jquery ou algum malabarismo de programação, com Ecma6 ficou muito mais prático e simples de aplicar.

[danguilherme]

@DaviDuqueNascimento fazer isso não torna o método privado. Isso é nada mais nada menos que uma convenção de nomenclatura, adotada justamente pela limitação da linguagem. Métodos privados são inacessíveis fora de seu escopo, por definição.

No fim, colocar underscore pra mascarar é só mais um dos "malabarismos" 🙂.

[danguilherme]

# is the new _: https://v8.dev/blog/v8-release-74#private-class-fields

class IncreasingCounter {
  #count = 0;
  get value() {
    console.log('Getting the current value!');
    return this.#count;
  }
  increment() {
    this.#count++;
  }
}

const counter = new IncreasingCounter();
counter.#count;
// → SyntaxError
counter.#count = 42;
// → SyntaxError

https://developers.google.com/web/updates/2018/12/class-fields

[ninetails]

TC39 Proposal (Stage 3)

Babel

[munizart]

@fernandomoraes eu raramente preciso de acesso privado mas quando preciso uso da seguinte forma:

function State (initial) {
  let state = initial

  return {
    set (value) {
      // ...
      state = value
    },

   log () {
     console.log(state)
   }
  }
}

[bozomj]

fiz um teste usando Arrow function atribuída a uma variável:

class MyClass {
       this.n1 = 5;
       this.n2 = 10;

       #somar = () =>  this.n1 + this.n2;

      calc() {
        return  this.#somar();
      }
 }

var my = new MyClass();

my.calc() // return 15;
my.#somar() // return private field

[souza-jefte]

Não dá certo todas as versões do Nodejs

[ninetails]

A partir do Node v13.2 com flag ou após v14.6.

Fonte: https://kangax.github.io/compat-table/esnext/
(isso se essa tabela estiver certa rs)

como na tabela diz, faz parte do esnext, não do es6... foi algo que foi inserido bem depois.