Por que devo usar classs ES6?

Eu tenho muitas dúvidas sobre as classs do ES6.

Desde que eu entendo como usar a function e WebComponent, Reagir e assim. Eu não vi muitos benefícios usando isso.

Eu me pergunto qual é o benefício de usar classs. Eu li que public / private / static fará parte do ES7. Então eu não vejo nenhum ponto de usá-lo atualmente.

Além disso, a class será um conceito de OOP ou ainda será um ‘conceito de object javascript‘? Isso significa que não posso modificá-lo usando .prototype ? Ou é apenas o mesmo object, mas duas maneiras diferentes de declará-lo.

Existe algum benefício com a velocidade? Talvez seja mais fácil manter / entender se você tem um grande aplicativo como o Big Java app?

tl;dr : The question is in the title.

INFORMAÇÃO : Eu noto que as pessoas ainda vêm para ver este q / a que é mais de 2 anos atrás agora. A resposta ainda é precisa, mas lembre-se que o javascript evoluiu “um pouco” desde então.

É (quase) inteiramente com você se você faz. A nova class é basicamente apenas açúcar sintático. (Mas, você sabe, o bom tipo de açúcar.)

Além disso, a class será um conceito de OOP ou ainda será um ‘conceito de object javascript’?

É a mesma inheritance prototípica que sempre tivemos, apenas com uma syntax mais limpa e mais conveniente. (Particularmente no caso de derivar de Array ou Error , o que você não poderia fazer no ES5 e anterior. Agora você pode Reflect.construct [ spec , MDN ], mas você deve tratar Array e Error especialmente quando derivar deles sem class , com class é exatamente o mesmo que derivar de qualquer outra coisa.)

Isso significa que não posso modificá-lo usando .prototype?

Não, você ainda pode modificar o object de prototype no construtor da class depois de criar a class. Por exemplo, isso é perfeitamente legal:

 class Foo { constructor(name) { this.name = name; } test1() { console.log("test1: name = " + this.name); } } Foo.prototype.test2 = function() { console.log("test2: name = " + this.name); }; 

Existe algum benefício com a velocidade?

Ao fornecer uma linguagem específica para isso, suponho que seja possível que o mecanismo consiga otimizar o trabalho. Mas eles são muito bons em otimizar já, eu não esperaria uma diferença significativa.

Por que devo usar classs ES6?

Razões que você pode escolher para:

  • A syntax é mais simples e menos propensa a erros.

  • É muito mais fácil (e novamente, menos propenso a erros) configurar hierarquias de inheritance usando a nova syntax do que com a antiga.

  • class defende-o do erro comum de não utilizar new com a function constructor (fazendo o construtor lançar uma exceção se this não for um object válido para o construtor).

  • Chamar a versão de um método do protótipo pai é muito mais simples com a nova syntax do que o super.method() antigo ( super.method() vez de ParentConstructor.prototype.method.call(this) ou Object.getPrototypeOf(Object.getPrototypeOf(this)).method.call(this) ).

  • Você pode derivar de Array (jQuery provavelmente teria feito isso, se fosse possível quando Resig o iniciou) e Error simplesmente, em vez de ter que usar Reflect.construct .

Aqui está uma comparação de syntax para uma hierarquia:

 // ES6 class Person { constructor(first, last) { this.first = first; this.last = last; } personMethod() { // ... } } class Employee extends Person { constructor(first, last, position) { super(first, last); this.position = position; } employeeMethod() { // ... } } class Manager extends Employee { constructor(first, last, position, department) { super(first, last, position); this.department = department; } personMethod() { const result = super.personMethod(); // ...use `result` for something... return result; } managerMethod() { // ... } } 

vs.

 // ES5 var Person = function(first, last) { if (!(this instanceof Person)) { throw new Error("Person is a constructor function, use new with it"); } this.first = first; this.last = last; }; Person.prototype.personMethod = function() { // ... }; var Employee = function(first, last, position) { if (!(this instanceof Employee)) { throw new Error("Employee is a constructor function, use new with it"); } Person.call(this, first, last); this.position = position; }; Employee.prototype = Object.create(Person.prototype); Employee.prototype.constructor = Employee; Employee.prototype.employeeMethod = function() { // ... }; var Manager = function(first, last, position, department) { if (!(this instanceof Manager)) { throw new Error("Manager is a constructor function, use new with it"); } Employee.call(this, first, last, position); this.department = department; }; Manager.prototype = Object.create(Employee.prototype); Manager.prototype.constructor = Manager; Manager.prototype.personMethod = function() { var result = Employee.prototype.personMethod.call(this); // ...use `result` for something... return result; }; Manager.prototype.managerMethod = function() { // ... }; 

Como você pode ver, muitas coisas repetidas e detalhadas que são fáceis de serem erradas e entediantes de redigitar (é por isso que eu escrevi um script para fazer isso , no passado).

As classs do ES6 são açúcar sintático para o sistema de classs prototípicas que usamos hoje. Eles tornam seu código mais conciso e auto-documentado, o que é razão suficiente para usá-los (na minha opinião).

Usando Babel para transpilar esta class ES6:

 class Foo { constructor(bar) { this._bar = bar; } getBar() { return this._bar; } } 

vai te dar algo como:

 var Foo = (function () { function Foo(bar) { this._bar = bar; } Foo.prototype.getBar = function () { return this._bar; } return Foo; })(); 

A segunda versão não é muito mais complicada, é mais código para manter. Quando você envolve inheritance, esses padrões se tornam ainda mais complicados.

Como as classs compilam os mesmos padrões prototípicos que estamos usando, você pode fazer a mesma manipulação de protótipos neles. Isso inclui adicionar methods e similares em tempo de execução, acessando methods em Foo.prototype.getBar , etc.

Há algum suporte básico para a privacidade no ES6 hoje, embora se baseie em não exportar os objects que você não deseja que sejam acessíveis. Por exemplo, você pode:

 const BAR_NAME = 'bar'; export default class Foo { static get name() { return BAR_NAME; } } 

e BAR_NAME não estará disponível para outros módulos para referência direta.

Muitas bibliotecas tentaram suportar ou resolver isso, como o Backbone com o seu auxiliar de extends que usa um hash não validado de funções e propriedades semelhantes a methods, mas não há um sistema consistente para expor uma inheritance prototípica que não envolva o protótipo .

À medida que o código JS se torna mais complicado e as bases de código são maiores, começamos a desenvolver muitos padrões para lidar com itens como inheritance e módulos. O IIFE usado para criar um escopo privado para módulos possui muitas chaves e parênteses; A falta de um desses pode resultar em um script válido que faz algo completamente diferente (pular o ponto-e-vírgula depois que um módulo pode passar o próximo módulo para ele como um parâmetro, o que raramente é bom).

tl; dr: é açúcar para o que já fazemos e deixa sua intenção clara no código.