Three.js: Avalie as aulas ES6

Então você está sugerindo usar esse padrão?

PointLight.prototype = Object.create( Light.prototype );
Object.assign( PointLight.prototype, {

class PointLight extends Light

hehe 😄 E sem problemas...

@sasha240100 algum dia...

@mrdoob não é bem assim - as duas maneiras que você menciona são diretamente equivalentes. Acho que o OP está comparando

PointLight.prototype = Object.assign( Object.create( Light.prototype ), { 
    constructor: PointLight,
    prop1: 'something',
    method1: function someFunction() { .. },
    ...
});

com

function PointLight () { ... };

PointLight.prototype = Object.create( Light.prototype );

PointLight.prototype.constructor = PointLight;

PointLight.prototype.prop1 = 'something';

PointLight.prototype.method1 = function someFunction() { .. };

...

Que é a maneira que é feito aqui, por exemplo.
Tanto quanto posso ver, esses estilos são equivalentes - há algo que estou perdendo?
Ou o estilo foi alterado para usar Object.Assign assim que ficou disponível e não foi atualizado na base de código?

@looeee @bfred-it @mrdoob Por que não usar rollup-babel ?

Comparação :
Atual. módulos de harmonia es5 + es6.

import { LineBasicMaterial } from './LineBasicMaterial';
import { Color } from '../math/Color';

function LineDashedMaterial( parameters ) {

    LineBasicMaterial.call( this );

    this.type = 'LineDashedMaterial';

    this.scale = 1;
    this.dashSize = 3;
    this.gapSize = 1;

    this.setValues( parameters );

}

LineDashedMaterial.prototype = Object.create( LineBasicMaterial.prototype );
LineDashedMaterial.prototype.constructor = LineDashedMaterial;

LineDashedMaterial.prototype.isLineDashedMaterial = true;

LineDashedMaterial.prototype.copy = function ( source ) {

    LineBasicMaterial.prototype.copy.call( this, source );

    this.scale = source.scale;
    this.dashSize = source.dashSize;
    this.gapSize = source.gapSize;

    return this;

};


export { LineDashedMaterial };

ES2015+. Mesmo código, mas es2015+ com babel-plugin-transform-class-properties :

import { LineBasicMaterial } from './LineBasicMaterial';
import { Color } from '../math/Color';

export class LineDashedMaterial extends LineBasicMaterial {
  type = 'LineDashedMaterial';

  scale = 1;
  dashSize = 3;
  gapSize = 1;
  isLineDashedMaterial = true;

  constructor(parameters) {
    super();
    this.setValues( parameters );
  }

  copy(source) {
    super.copy(source);

    this.scale = source.scale;
    this.dashSize = source.dashSize;
    this.gapSize = source.gapSize;

    return this;
  }
}

Recursos do ES6 que simplificariam o código three.js:

• Valores de parâmetro padrão.
  
  
  
  • O pode substituir facilmente essas partes do código
  
  
• Abreviação de propriedade
  
  
  
  • Pode ser usado aqui
  
  
• Função de seta
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

Eu sou a favor da mudança para o ES2015+, só precisamos encontrar uma maneira de gerar código semelhante ao que temos atualmente, para que o desempenho permaneça o mesmo em todos os casos.

Tenho uma dúvida no contexto das aulas. Como transferiríamos métodos como Vector3.unproject para a sintaxe da classe? Na verdade, o método usa um encerramento para criar um novo escopo. Esse é um mecanismo importante que mantém a quantidade de criações de objetos o mais baixa possível.

Precisamos de Object.assign nestes casos?

@Mugen87 @mrdoob Algumas informações interessantes sobre o desempenho do es6. Especialmente em Object.assign :

A partir deste artigo

Como transferiríamos métodos como Vector3.unproject para a sintaxe da classe? Na verdade, o método usa um encerramento para criar um novo escopo.

@ Mugen87 Eles não podem ser apenas objetos com escopo de módulo não exportados? Algo assim;

const tempMatrix = new Matrix();    

export default class Vector3{
    unproject() {
        // uses tempMatrix
    }
}

Ah sim, acho que isso deve funcionar 😊

No mês passado, isso foi sugerido no twitter :

https://astexplorer.net/#/gist/9db8b707e3f69f94ded4af737f879fa7/b12fb12806e97df96278ec8b7d52018c8421872f

@mrdoob Uau! Parece que já está funcionando. Não podemos fazer um branch, transformar algumas classes em es6 e ver como ele compila?

@satori99 Como uma ideia de como manter tempMatrix dentro do código Vector3 para evitar problemas com globais:

export default class Vector3 {
    static tempMatrix = new Matrix();

    unproject() {
        // uses Vector3.tempMatrix
    }
}

@mrdoob Uau! Parece que já está funcionando. Não podemos fazer um branch, transformar algumas classes em es6 e ver como ele compila?

Soa bem para mim! Atualmente estou focando em WebVR, então precisará ser outra pessoa além de mim.

@sasha240100 O benefício de usar vars com escopo de módulo é que eles permanecem ocultos do código de usuário regular, o que parece apropriado para variáveis ​​temporárias.

Eu não me importo com a abordagem pythonística "Somos todos adultos aqui" em relação a vars privados, mas as variáveis ​​temporárias não devem realmente poluir o namespace desnecessariamente.

Além disso, seria bom se aqueles de nós que habilitaram o suporte a módulos nativos em nossos navegadores pudessem carregar os arquivos src diretamente. Esta é uma maneira muito mais agradável de desenvolver, sem precisar de observadores e transpilar após cada edição. Usar propriedades de classe significa que isso não é possível, pois elas não fazem parte da especificação de classe atual.

Desculpas por se intrometer. Provavelmente deveríamos mudar o título do problema para algo como - "Avaliar classes ES6", já que agora o tópico mudou para algo completamente diferente.

Por que mudar o padrão @Mugen87 @satori99 ?

method =(()=>{ 
    const vec3forThisScope =...; 
    return (arg)=>{...}
})()

Por que não tentar typescript, ele pode ser compilado em outras versões do js

TypeScript realmente seria uma ótima opção para se pensar porque é um transpilador + verificador de tipos e um superconjunto de JavaScript, então é fácil mover uma base de código para arquivos .ts e refatorar gradualmente para ES6 com verificação de tipos.

Pode parecer assustador se você nunca usou o TypeScript, mas na verdade não é uma grande curva de aprendizado e seria um preço pequeno a pagar pelos benefícios que traria. A comunidade TypeScript ficaria muito feliz em ajudar nessa transição e na criação de testes de desempenho em relação à biblioteca atual para garantir que ela não seja rebaixada.

Alguns artigos úteis:

• Por que você não deve ter medo do TypeScript
• TypeScript vs ES6 vs ES2015
• TypeScript ganhou
• O que é TypeScript e por que com Anders Hejlsberg

Para citar o desenvolvedor principal Anders Hejlsberg, o TypeScript nasceu em resposta a reclamações de clientes e equipes internas de que o JavaScript não se prestava bem a grandes aplicativos.

O objetivo era "fortalecer o JavaScript com coisas como classes, módulos e tipagem estática", sem sacrificar a vantagem de ser de padrões abertos e multiplataforma; o resultado foi uma "linguagem para desenvolvimento javascript em escala de aplicação", construída como um superconjunto da linguagem.

Até que os navegadores possam executar o TypeScript nativamente, prefiro continuar usando JavaScript.

@mrdoob

Não consigo ver isso como um motivo válido para não usar o TypeScript apenas porque ele não pode ser executado diretamente no navegador. Você não gostaria que ele fosse executado no navegador por causa de todas as linhas extras de código destinadas apenas à verificação de tempo de compilação. Atualmente, não é uma linguagem de verificação de tempo de execução. Portanto, se ele já foi usado no navegador, é mais do que provável que todo o código digitado seja removido porque afeta o desempenho e isso seria um código JavaScript vanilla.

Acho que você está perdendo totalmente o ponto de usar uma linguagem tipada e os benefícios que ela tem no desenvolvimento em uma grande base de código. Você ainda está escrevendo e usando JavaScript, o ponto principal do TypeScript é que ele é um superconjunto de JavaScript. Você escreve JavaScript com tipos, que são compilados em JavaScript na versão de destino ECMAScript especificada, que é configurável nas opções do compilador, os valores permitidos são 'es3', 'es5', 'es2015', 'es2016', 'es2017' ou ' esnext'.

Como o Typescript é JavaScript, é possível migrar progressivamente sem ter uma enorme dor de cabeça de refatorar tudo de uma vez. Ele pode ser feito gradativamente e melhorado pela comunidade. Não é mais trabalhoso do que o que está sendo discutido aqui com refatoração para usar classes ES6. Essa é a única razão pela qual menciono aqui em vez de abrir uma nova edição.

Veja os links de playground do TypeScript abaixo para ótimos exemplos:

• Exemplo de JavaScript clássico
• Exemplo de adição de tipos
• Adicionando Tipos com Exemplo de Erro
• Exemplo de uso de classes
• Usando classes com erro Exemplo

@joejordanbrown

Você consegue pensar em alguém que poderia discordar de você sobre o texto datilografado ser a melhor solução para esse problema específico?

Se você digitar typescript vs no google, alguns termos aparecerão, sendo um deles Flow. Procurando por isso, parece render uma série de artigos onde as pessoas estão debatendo os prós e contras desses dois.

Nenhum tipo parece mais um compromisso do que escolher um desses.

Salve o Typescript para projetos que são mais complicados do que o resultado que eles criam -- especialmente frameworks front-end que poderiam ter sido implementados em HTML em primeiro lugar. Meu objetivo original era livrar-se da doença do JavaScript, não torná-la pior. JavaScript é uma linguagem simples quase de brinquedo que às vezes é usada para resultados complexos como three.js. Texto datilografado é inútil.

Em 6 de setembro de 2017, às 13h55, Joe [email protected] escreveu:

@mrdoob

Não consigo ver isso como um motivo válido para não usar o TypeScript apenas porque ele não pode ser executado diretamente no navegador. Você não gostaria que ele fosse executado no navegador por causa de todas as linhas extras de código destinadas apenas à verificação de tempo de compilação. Atualmente, não é uma linguagem de verificação de tempo de execução. Portanto, se ele já foi usado no navegador, é mais do que provável que todo o código digitado seja removido porque afeta o desempenho e isso seria um código JavaScript vanilla.

Acho que você está perdendo totalmente o ponto de usar uma linguagem tipada e os benefícios que ela tem no desenvolvimento em uma grande base de código. Você ainda está escrevendo e usando JavaScript, o ponto principal do TypeScript é que ele é um superconjunto de JavaScript. Você escreve JavaScript com tipos, que são compilados em JavaScript na versão de destino ECMAScript especificada, que é configurável nas opções do compilador, os valores permitidos são 'es3', 'es5', 'es2015', 'es2016', 'es2017' ou ' esnext'.

Como o Typescript é JavaScript, é possível migrar progressivamente sem ter uma enorme dor de cabeça de refatorar tudo de uma vez. Ele pode ser feito gradativamente e melhorado pela comunidade. Não é mais trabalhoso do que o que está sendo discutido aqui com refatoração para usar classes ES6. Essa é a única razão pela qual menciono aqui em vez de abrir uma nova edição.

Consulte os links de playground do TypeScript para obter exemplos:

Exemplo de JavaScript clássico
Exemplo de adição de tipos
Adicionando Tipos com Exemplo de Erro
Exemplo de uso de classes
Usando classes com erro Exemplo
—
Você está recebendo isso porque foi o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

^ eu ficaria bem mesmo com o padrão monstruoso, desde que seja consistente.

@joejordanbrown parece que você está apaixonado por texto datilografado. sinta-se à vontade para fazer um fork do projeto e portá-lo para o typescript. três.ts! 🙌

@pailhead

Isso é uma questão de escolha, tenho certeza que muitos vão concordar e discordar, isso é normal, mas certo! Você sempre verá "isto versus aquilo", "o meu é melhor que o seu". Eu entendo que cada um tem seus próprios benefícios. Trata-se de avaliar as opções disponíveis e ver se elas podem beneficiar o projeto. As comparações são uma coisa boa, isso leva os projetos adiante.

Você menciona o Flow, os problemas que vejo com isso são:

• O licenciamento de fluxo é BSD 3-clausula " Facebook BSD + Patents License ", a Apache Software Foundation proibiu o uso desta licença em novos projetos. Você pode ler mais detalhes aqui .

• O suporte IDE está faltando em comparação com o TypeScript.

• A base de usuários é pequena em comparação com o TypeScript,

• As tipagens disponíveis para bibliotecas públicas estão incompletas, o TypeScript tem muitas tipagens bem mantidas.

• Documentação e recursos são difíceis de encontrar e são vagos comparados ao TypeScript, você encontrará ótima documentação, livros, vídeos e muitos outros recursos de e-learning.

• O Flow usa arquivos .js sinalizados com // @flow , isso pode ser confuso porque você vê a extensão .js , então espere JavaScript, mas, na verdade, é FlowType. Onde o TypeScript usa sua própria extensão .ts . Isso também permite que você tenha os arquivos de saída TypeScript e JavaScript com nomes idênticos no mesmo diretório, o que é ideal para um projeto pequeno, obviamente, mas não seria o caso em um projeto grande, porque você estaria usando um build sistema para gerenciar o processo de compilação.

Até o Google está apoiando o TypeScript em grande estilo, isso mostra a confiança que eles têm no TypeScript. Leia o post aqui ou aqui .

O Typescript foi permitido para o desenvolvimento irrestrito do cliente em março de 2017. O TypeScript e o Angular no TypeScript são usados ​​no Google Analytics, Firebase e Google Cloud Platform e ferramentas internas críticas, como rastreamento de bugs, análises de funcionários e ferramentas de aprovação e lançamento de produtos.

Eu apenas pensei em abrir a discussão sobre o uso de uma linguagem tipada e ver o que todos os outros pensam sobre a ideia. Parece que @mrdoob é totalmente contra até mesmo discutir a ideia.

@arctwelve
Não vejo como esse projeto não seja complicado e como o uso de uma linguagem tipada o afetaria negativamente.

@mrdoob
De forma alguma, posso apenas ver os benefícios que isso poderia ter, especialmente se uma nova ramificação estiver sendo criada para atualizar para as classes ES6. Acho que responder com criar seu próprio fork chamado three.ts é apenas ser bobo. Isso é realmente contra as boas práticas de OSS se todos apenas fizerem um fork de projetos de OSS e modificarem seu próprio código-fonte em vez de se concentrar no projeto 1 e torná-lo o melhor possível. Você acabaria com softwares ou comunidades realmente ruins se dividindo e se concentrando no projeto que preferem por qualquer motivo. Por que você não pode ter uma discussão aberta sobre os prós e contras?

Não para bancar o advogado do diabo, mas parece que ele fez

ter uma discussão aberta

foi bem curtinho :)

Compartilho um ponto de vista semelhante, é uma biblioteca JS e JS é padronizado. Você não pode errar ao escolher JS para uma biblioteca JS, enquanto pode se escolher outra coisa. Acabei de tomar o Flow como uma das alternativas ao texto datilografado, não sei se existem outras.

De qualquer forma, parece que realmente saímos do assunto.

Mugen87 mudou o título de
Remova a doença do JavaScript para avaliar as classes ES6

O título original referia-se (pelo que entendi) à falta de consistência de estilo. Em particular usando Object.assign() em alguns lugares e outro padrão em outros.
Se eu avaliasse alguma coisa aqui, seria o título atual da edição. Por que a questão da consistência está sendo elevada a uma discussão sobre o uso de uma nova linguagem?

Imagino que com typescript e es6, o código deve ser bastante consistente.

Eu resolveria esse problema atualizando esta página:

https://github.com/mrdoob/three.js/wiki/Mr.doob 's-Code-Style%E2%84%A2

e adicionando:

A) "...use Object.assign ..."
B) "... não use Object.assign"

Um estilo em toda a biblioteca. Não há necessidade de alterá-lo.

O fiel estilo de duas linhas ainda, por exemplo, nas classes de Materiais são muito mais claros e limpos.

Está no primeiro post.

Eu sugiro:

1. edite o título para refletir esta frase, discuta sobre ter um estilo em toda a biblioteca, editando o guia de estilo etc.
2. iniciar uma nova discussão intitulada "avaliar as classes es6", onde as classes es6 seriam avaliadas
3. iniciar uma nova discussão intitulada "avaliar tendo três escritos em uma linguagem datilografada", onde o texto datilografado e afins seriam discutidos

De qualquer forma, parece que realmente saímos do assunto.

De fato. @joejordanbrown sinta-se à vontade para criar um novo tópico para discutir o TypeScript.

Aliás, também é uma prática ruim do OSS ignorar conversas anteriores... https://github.com/mrdoob/three.js/issues/341#issuecomment -47000692

De volta ao tópico. Achei que já resolvemos esse problema?

https://github.com/mrdoob/three.js/issues/11552#issuecomment -319449068

Só precisamos de alguém para tentar.

Ok então... em primeiro lugar

Primeiro padrão (o melhor IMO):

function MyClass() {...}

MyClass.prototype = Object.assign( Object.create( MyClassToInherit.prototype ), {

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

O segundo padrão:

function MyClass() {...}

MyClass.prototype = Object.create( MyClassToInherit.prototype );

MyClass.prototype.constructor = PointLight;

MyClass.prototype.prop1 = 'something';

MyClass.prototype.method1 = function someFunction() { .. };

...

@arctwelve Este padrão foi introduzido por vários motivos. Isso não é masturbação!

Em primeiro lugar, permite uma leitura clara sobre a herança de objetos. O Object.assign é claramente aqui sobre a herança do objeto. Então você não pode perder o objeto herdado em muitas e muitas linhas de MyClass.prototype .
Em segundo lugar, no caso de herança múltipla, isso também é muito mais claro.
Terceiro, o construtor da classe é legível e não se perde em muitas linhas como o primeiro ponto.
Quarto, isso permite agrupar propriedades e métodos no mesmo local ( entre colchetes ) o que fica muito mais claro quando você tem 3, 4, 5... etc classes no mesmo arquivo.
Quinto, este padrão permite verificar a cópia correta de algumas propriedades "herdadas".

Finalmente ( @looeee ), isso também é para desempenho. A primeira versão é mais otimizada quando ocorre a análise de arquivos, em vez de chamadas múltiplas e múltiplas para o protótipo.

De qualquer forma !

Hoje em dia, devemos passar para a sintaxe ES6!

@mrdoob

Soa bem para mim! Atualmente estou focando em WebVR, então precisará ser outra pessoa além de mim.
Só precisamos de alguém para tentar.

Você criaria um branch es6? Ou é por nossa conta?

A primeira versão é mais otimizada quando ocorre a análise de arquivos, em vez de chamadas múltiplas e múltiplas para o protótipo.

Você tem certeza sobre isso? Eu esperaria que Object.Assign fosse mais lento, se alguma coisa. Mas, em ambos os casos, duvido que seja uma sobrecarga de desempenho suficiente para se preocupar.

Absolutamente: https://jsperf.com/inline-prototype-vs-assign-prototype/1

Na versão chrome 61.0.3163.100 (Build officiel) (64 bits) O protótipo atribuído é cerca de 60% mais rápido

Interessante. Obrigado por fazer o teste.

Esse resultado não é válido para todos os navegadores. No Firefox eles são quase os mesmos ( Object.Assign ~3% mais rápido), enquanto no Edge Object.Assign é ~33% mais lento .

Mas, em qualquer caso, eu ainda não acho que isso seja relevante como um argumento para qual estilo é melhor - mesmo o mais lento geral (proto inline no Chrome) ainda está sendo executado em> 180.000 operações por segundo, e talvez haja alguns milhares de essas configurações feitas no código. Então, estamos falando de uma diferença de alguns milissegundos aqui, provavelmente.

Para mim, o estilo Object.Assign é mais limpo e fácil de ler, e esse é o principal argumento a favor dele.

Sim, isso é cerca de alguns milissegundos por arquivo e somente quando o arquivo é analisado pela primeira vez pelo mecanismo javascript ... mas para uma grande biblioteca como o threejs o ganho pode ser razoavelmente em torno de 200 milissegundos no carregamento da página.
Não se esqueça do limite de 3scd para usuários frontais que não podem esperar mais!

Estou tentando fazer um projeto Angular com threejs e sempre parece que estou hackeando todas as partes do threejs.
Em primeiro lugar, é a sintaxe es5 com TRÊS constantes que devem existir, por exemplo, se eu precisar de OrbitalControls.
Temos três tipos de js, mas será mais conveniente tê-los no mesmo pacote. As tipagens têm OrbitalControls, mas não podemos simplesmente importar como import { OrbitalControls } from 'three; .
Webpack tem tree shake, então no caso do es6 podemos incluir tudo o que precisamos dentro de um projeto e não movê-los para um separado.
@mrdoob então por que o Typescript é tão ruim? Será compilado para ES qualquer versão com tipagens de qualquer maneira.
Também é usado em muitos outros frameworks como React.

@FriOne Não tenho certeza se @mrdoob realmente acha que o Typescript é ruim, mas acho que ele é contra discutir o Typescript nesta questão/tópico porque não é o tópico deste tópico. Eu acho que as classes ES6 não funcionam contra ou para Typescript. Se você transformar a base de código para ES6, é ainda mais fácil portar a base de código para o Typescript porque sua sintaxe é muito semelhante. Sim, acho que o Typescript pode habilitar muitas novas opções. Por exemplo, pode ajudar a "transpilar" um código mais otimizado, ajuda novos desenvolvedores a aprender a biblioteca mais rápido, talvez abra portas para experimentos no futuro, por exemplo: https://github.com/AssemblyScript/assemblyscript. Acho que há muitas vantagens com o Typescript @joejordanbrown descreveu os profissionais em detalhes.

Mas voltando ao tópico: acho que adotar as classes ES6 seria um passo à frente e depois disso, poderíamos discutir a coisa do Typescript. Então vamos dar um passo após o outro

@tschoartschi , acho que o typescript pode ajudar na migração para classes es6 e outras refatorações. Eu não tenho essa experiência de migração, pode ser que eu esteja errado.

@FriOne , depende 😉 é claro que o Typescript pode ajudar porque o compilador pode informar todos os seus erros e erros, mas você precisaria configurar todo o tubo de compilação primeiro para trabalhar com o Typescript. Além disso, você precisa avaliar se o Typescript é o ajuste correto ou não. Eu acho que é bom converter para classes ES6 primeiro e depois pensar em Typescript.

Ei, somos um grupo de 5 alunos da KTH procurando contribuir para um projeto de código aberto para um curso e gostaríamos de tentar converter uma parte do projeto para a nova sintaxe ES6.

Eu portei o Three.js para o TypeScript um tempo atrás (r82) junto com alguns dos exemplos, como uma prova de conceito.

https://github.com/flyover/three.ts

Os exemplos demoram um pouco para carregar, pois a fonte do TypeScript é transpilada na hora. Eles carregam tão rápido quanto os originais ao usar o JavaScript transpilado.

Eu adoraria ver three.js portado para typescript. Eu sinto que o projeto precisa ser modernizado se quiser resistir ao teste do tempo para as próximas gerações da web. Um dia, podemos até vê-lo funcionando com AssemblyScript e rodando em WASM. Se não for threejs, então outra coisa certamente o fará.

Isso está concluído @WestLangley e @mrdoob

@bhouston qual é a conclusão aqui?

@pkieltyka sim, também acho que o TypeScript faria muito sentido para uma biblioteca como Three.js. Além de todos os profissionais técnicos, também facilitaria o uso da biblioteca e ajudaria os novatos a explorar a API. Mas também acho importante terminar todas as coisas do ES6 primeiro e depois considerar o TypeScript. Acho que a partir do JavaScript mais recente não é muito complicado adicionar tipos na forma de TypeScript.

@flyover legal também ver uma prova de conceito para uma versão TypeScript do Three.js. Você recebeu feedback dos mantenedores do Three.js?

Eu também apoio typescript para three.js. typescript é basicamente o melhor
prática e JavaScript bruto não é mais.

Em sáb, 5 de janeiro de 2019, 04:13 tschoartschi < [email protected] escreveu:

@pkieltyka https://github.com/pkieltyka sim, eu também acho TypeScript
faria muito sentido para uma biblioteca como Three.js. Ao lado de todos os
profissionais técnicos, também facilitaria o uso da biblioteca e ajudaria os novatos
para explorar a API. Mas também acho importante terminar todo o ES6
Coisas primeiro e, em seguida, considere o TypeScript. acho que desde o último
JavaScript não é muito complicado adicionar tipos na forma de TypeScript.

@flyover https://github.com/flyover legal também ver uma prova de conceito para
uma versão TypeScript do Three.js. Você recebeu feedback dos mantenedores
de Três.js?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451639995 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAj6_bkdND7I0_F4AJcBV0DYLpToUIVhks5vAGykgaJpZM4N9vH8
.

@bhouston Concordo que o TypeScript é uma ótima tecnologia, mas não colocaria do jeito que você fez. Acho que devemos sempre ficar o mais próximo possível do JavaScript bruto e adicionar os recursos do TypeScript no topo. Como o TypeScript segue muito de perto as especificações do JavaScript, o TypeScript realmente lê como ES6 com tipos.

Para uma biblioteca como a three.js, o TypeScript pode ser realmente benéfico e pode ser adotado gradualmente. Portanto, não precisaríamos de uma reescrita "big-bang", especialmente depois que todas as refatorações do ES6 estiverem concluídas.

Seria interessante saber se a postura do @mrdoob no TypeScript mudou. O TypeScript parece se tornar o padrão "de fato" para "javascript digitado" (observe que coloco minhas reivindicações sob apóstrofo, pois não são fatos concretos)

O primeiro passo deve ser adotar os recursos do ES6, especialmente classes, função de seta, 'let' e 'const'.

Uma vez feito isso, podemos discutir adequadamente o suporte ao typescript, pois, como aponta @roomle-build, é fácil adicionar recursos de typescript de forma incremental no código ES6 gradualmente, se decidirmos.

Fazer as duas coisas ao mesmo tempo parece que complicaria demais as coisas, para mim.

Ótimo saber que o TypeScript pode ser uma opção em algum momento no futuro :-) talvez possamos reutilizar alguns dos trabalhos feitos por @flyover

Mas eu concordo totalmente com @looeee para terminar todas as coisas do ES6 primeiro e depois focar nos próximos passos

terminar todas as coisas do ES6

Ficaria feliz se pudéssemos pelo menos começar 😅

Um bom meio passo para o TypeScript seria adicionar arquivos de tipo ao lado de cada arquivo JavaScript. Assim haveria ambos:

Vector3.js
Vector3.d.ts

Isso nos dá todos os benefícios do TypeScript como arquivos secundários.

No momento, existe um arquivo @types/three, mas está desatualizado e mantido separadamente - portanto, estará sempre sem dados.

O principal concorrente do Three.JS é o Babylong e é totalmente datilografado e acredito que se beneficie disso.

Mas matar @types/three e integrá-lo como arquivos de definição de tipo de side cars no Three seria um ótimo primeiro passo.

Também precisamos obter todos os exemplos integrados em /src com algum tipo de trepidação de árvore.

No momento, a estrutura de código para Three.JS é tão 2014 e apenas uma dor de cabeça para trabalhar.

Todos os exemplos?

Exemplos/js

Em segunda-feira, 7 de janeiro de 2019, 10h25 Dusan Bosnjak < [email protected] escreveu:

Todos os exemplos?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
.

@bhouston

Um bom meio passo para o TypeScript seria adicionar arquivos de tipo ao lado de cada arquivo JavaScript. Assim haveria ambos:

Vector3.js
Vector3.d.ts

Os arquivos .d.ts agiriam como arquivos .h em c?

Os arquivos .d.ts agiriam como arquivos .h em c?

Essa é uma analogia muito boa. Interessante alguém já fez a maior parte disso aqui: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/three Assim, realmente seria apenas apropriar-se desses arquivos de tipo e integrá-lo ao Three.js. Se você quiser, podemos criar um PR que integre isso ao Three.js e divida-o corretamente.

Para mostrar a popularidade do Typescript, veja quantos @Types/three são baixados por semana:

https://www.npmjs.com/package/@types/three - 63.000 downloads por semana.

Impressionante!

Se você quiser, podemos criar um PR que integre isso ao Three.js e divida-o corretamente.

Parece bom para mim 👍

É possível executar uma verificação de linha de comando, semelhante ao eslint, garantindo que os arquivos de tipo e os arquivos de origem .js estejam alinhados? Se estivermos nos apropriando dos arquivos d.ts , seria altamente preferível ter alguma forma de verificar regularmente se eles correspondem.

Para mostrar a popularidade do Typescript, veja quantos @Types/three são baixados por semana:

https://www.npmjs.com/package/@types/three - 63.000 downloads por semana.

Eu atribuiria isso mais à popularidade do Visual Studio Code, porque isso acontece automaticamente quando você usa o Visual Studio Code, por meio do recurso Automatic Type Acquisition.
Dito isto, não pode ser ignorado.

@flyover @bunnybones1 @mrdoob @looeee @donmccurdy @bhouston @roomle-build @pkieltyka @FriOne @joejordanbrown já que todos vocês parecem estar interessados ​​no TypeScript, eu queria observar que criei um novo problema sobre o TypeScript. Acho que faz sentido mover todas as discussões do TS para lá. Se você estiver interessado, pode encontrá-lo aqui: https://github.com/mrdoob/three.js/issues/15545

Estou disposto a dedicar tempo para portar para as classes ES6. Acho que esta será uma boa solução de ponte para um dia suportar o Typescript.

O primeiro passo é converter alguns dos complementos para ES6.

https://github.com/mrdoob/three.js/tree/dev/examples/jsm

Controles, Carregadores e Exportadores são bons candidatos. Sinta-se à vontade para ajudar!

@mrdoob apenas para confirmar, você quer dizer convertê-los em módulos ES, mas ainda não usando outros recursos do ES6, certo?

Suponho que o processo de fazer essa conversão seja:

1. Use o script modularize.js para converter o arquivo original em um módulo ES.
2. Limpe os problemas, se necessário.
3. Em algum momento (neste lançamento, ou em um futuro próximo) começaremos a usar rollup-examples.config.js para converter os módulos ES em módulos UMD, quando a versão em examples/js não é mais mantida por mão.
4. Uma vez que esteja estável, podemos considerar outras mudanças, como a introdução de recursos do ES6.

@mrdoob apenas para confirmar, você quer dizer convertê-los em módulos ES, mas ainda não usando outros recursos do ES6, certo?

Sim, desculpe-me. Eu deveria ter especificado.

Eu e @bhouston criamos o PR prometido que contribui com os arquivos *.d.ts para a maior parte do projeto Three.JS. https://github.com/mrdoob/three.js/pull/15597

Mal posso esperar pelas classes ES6 e definições Typescript. Toda vez que estou trabalhando com three.js eu tenho que copiar e colar centenas de linhas de código para reimplementar uma função que está em um escopo inacessível. Não é realmente uma maneira elegante de trabalhar se você tiver que otimizar suas cenas. Levaria o fluxo de trabalho a um novo nível para finalmente poder estender e substituir funções.
Então, por favor, torne as funções de classe pelo menos „protegidas“ e acessíveis sem exceção 🤗

Toda vez que estou trabalhando com three.js eu tenho que copiar e colar centenas de linhas de código para reimplementar uma função que está em um escopo inacessível. ... Então, por favor, torne as funções de classe pelo menos „protegidas“ e acessíveis sem exceção.

@dionysiusmarquis Não tenho certeza se entendi o que você quer dizer aqui ... as tipagens TS existentes têm funções que você deseja usar marcadas incorretamente como privadas? Ou algo sobre as atuais definições de classe no estilo protótipo torna difícil o uso do TS? Você poderia compartilhar um exemplo?

Toda vez que estou trabalhando com three.js eu tenho que copiar e colar centenas de linhas de código para reimplementar uma função que está em um escopo inacessível. ... Então, por favor, torne as funções de classe pelo menos „protegidas“ e acessíveis sem exceção.

@dionysiusmarquis Não tenho certeza se entendi o que você quer dizer aqui ... as tipagens TS existentes têm funções que você deseja usar marcadas incorretamente como privadas? Ou algo sobre as atuais definições de classe no estilo protótipo torna difícil o uso do TS? Você poderia compartilhar um exemplo?

Eu só queria implementar um mapa de sombra específico para um cenário específico. Teria ajudado poder substituir getDepthMaterial por exemplo. No momento eu injeto meu próprio WebGLShadowMap no processo de construção com uma versão de copiar/colar incluindo minhas alterações desejadas.
Seria tão bom se cada classe three.js pudesse expor o máximo possível. Com typescript você pode facilmente sinalizar funções como private ou protected para descrever o propósito pretendido. Meu ShadowMap ES6 Class/Typescript, por exemplo, se parece com isso:

interface MaterialCache {
  [uuid: string]: {[uuid: string]: MeshDepthMaterial}
}

class ShadowMap {
  public enabled: boolean = false
  public autoUpdate: boolean = true
  public needsUpdate: boolean = false
  public type: ShadowMapType

  …

  protected depthMaterials: MeshDepthMaterial[]
  protected materialCache: MaterialCache

  constructor (renderer: WebGLRenderer, objects: WebGLObjects, maxTextureSize: any) {
    …
  }

  protected getDepthMaterial (object: Object3D, material: Material) {
    …
  }
}

export { ShadowMap as WebGLShadowMap }

Parece em casa se você tiver permissão para modificar classes de "baixo nível"

Tenho uma dúvida no contexto das aulas. Como transferiríamos métodos como Vector3.unproject para a sintaxe da classe? Na verdade, o método usa um encerramento para criar um novo escopo. Esse é um mecanismo importante que mantém a quantidade de criações de objetos o mais baixa possível.

Precisamos de Object.assign nestes casos?
@Mugen87

Você pode fazer encerramentos com classes agora. Não é óbvio como navegar nesse açúcar sintático. Veja minha resposta no StackOverflow: https://stackoverflow.com/questions/39297258/iife-in-es6-class-literal/56077521#56077521 (devo ser humilde e admitir que não entendo completamente como/por que funciona .)

Desculpe, mas este código parece um anti-padrão e não devemos adaptar isso no projeto. Existem soluções adequadas para gerenciar variáveis ​​no escopo do módulo. Sugiro seguir este caminho.

@ Mugen87 sim, também acho que devemos fazer bom uso do escopo do módulo. Isso também ajudaria em coisas como sacudir árvores. Isso já foi discutido em muitas outras questões como esta: https://github.com/mrdoob/three.js/issues/6241#issuecomment -398703521

Desculpe, mas este código parece um anti-padrão e não devemos adaptar isso no projeto. Existem soluções adequadas para gerenciar variáveis ​​no escopo do módulo. Sugiro seguir este caminho.

Sem problemas. Acabei de mencionar a possibilidade. Se você tiver uma solução melhor/mais limpa em andamento, estou ansioso para vê-la em ação. O projeto Three.js (uso, fonte, discussões etc.) tem sido minha principal fonte de conhecimento de JS, então introduzir novos e melhores padrões de programação para Three.js provavelmente beneficiará a mim e meus projetos também. Nada a lamentar. ;-)

@ Mugen87 Você pode elaborar um pouco sobre por que você considera os class-IIFEs um anti padrão, se apenas para que eu possa aprender e entender um pouco mais? Eu entendo que os módulos abrangem variáveis ​​inerentemente, mas isso não é diferente de como o núcleo estava sendo construído anteriormente. E com tantas funções usando variáveis ​​de cache, será muito importante garantir que nenhuma das funções colida ou use variáveis ​​ao mesmo tempo - o escopo da função facilita o gerenciamento e a manutenção, e é por isso que não vejo como um antipadrão (pelo menos quando comparado ao lançamento de todas as variáveis ​​de cache no escopo do módulo).

Você pode elaborar um pouco sobre por que você considera as classes IIFEs um antipadrão

Eu não usaria uma abordagem que potencialmente impedisse o tremor de árvore, como mencionado aqui: https://github.com/mrdoob/three.js/pull/14695. Além disso, acho que todo o padrão parece um hack. Usar abordagens menos "fantasiosas" geralmente funciona melhor. Evitar fechamentos desnecessários também deve melhorar o desempenho de execução de código em geral (não posso provar isso com uma referência, mas ouvi isso em uma palestra há algum tempo).

E com tantas funções usando variáveis ​​de cache, será muito importante garantir que nenhuma das funções colida ou use variáveis ​​ao mesmo tempo.

Os IIFEs são usados ​​principalmente nas aulas de matemática. Como temos uma boa cobertura de teste lá ( @gero3 fez um ótimo trabalho recentemente adicionando mais testes de unidade), deve ser mais fácil tornar a remoção deles robusta.

Não há problema em remover IIFEs. Acho que sou responsável por isso em 2013. Foi para se livrar de um padrão de variável estática que era difícil de manter. Foi feito neste PR:

https://github.com/mrdoob/three.js/pull/2941

https://github.com/mrdoob/three.js/issues/2936

E discutido ainda mais cedo aqui:

https://github.com/mrdoob/three.js/pull/2920#issuecomment -12217793

Fato interessante, quando os colocamos, não houve diferença no desempenho do código.

Suponho que o processo de fazer essa conversão seja:

1. Use o script modularize.js para converter o arquivo original em um módulo ES.
2. Limpe os problemas, se necessário.
3. Em algum momento (neste lançamento, ou em um futuro próximo) começaremos a usar rollup-examples.config.js para converter os módulos ES em módulos UMD, quando a versão em examples/js não é mais mantida por mão.
4. Uma vez que esteja estável, podemos considerar outras mudanças, como a introdução de recursos do ES6.

Ei. pode ter perdido, mas quais foram nossos passos incrementais em direção às aulas?

1. [x] Use o script modularize.js para converter o arquivo original em um módulo ES.
2. [x] Limpe os problemas, se necessário.
3. [ ] Em algum momento (neste lançamento, ou em um futuro próximo) começaremos a usar rollup-examples.config.js para converter os módulos ES em módulos UMD, quando a versão em example/js não será mais mantida por mão.
4. [ ] Uma vez que esteja estável, podemos considerar outras mudanças, como a introdução de recursos do ES6.

Nas etapas acima, basicamente concluímos as etapas (1) e (2).

Etapa (3) não estamos mais fazendo dessa maneira, mas vamos descontinuar e remover a pasta examples/js em algum momento (consulte https://github.com/mrdoob/three.js/pull/18749) .

Eu acho que isso significa que o passo (4), introduzir classes ES6 para examples/jsm só pode ser feito (por enquanto) nos poucos exemplos que não são gerados a partir de versões de origem examples/js . Assim que examples/js for removido, podemos fazer o resto.

^ Mas eu posso estar lendo muito nas entrelinhas aqui, talvez @Mugen87 ou @mrdoob possam confirmar?

IMO, o projeto deve se concentrar na descontinuação e remoção de examples/js para obter uma base de código somente de módulo. Na próxima etapa, eu recomendaria seguir em frente com a migração de classe. Começando com os exemplos e depois migrando o core.

perfeito. obrigado. vai dar uma olhada nessas maneiras

Repostado de edição encerrada.
Olá,

Eu queria criar este problema para tentar descobrir a opinião de todos sobre como gostaríamos de avançar com a migração de turmas.

Meu resumo rápido do que encontrei até agora:

• Devemos depreciar a pasta de exemplos antes de fazer qualquer outra coisa
• Existem partes do src/ que não são estendidas por nenhum dos exemplos que podem ser convertidos
• Com algumas mudanças no script modularize.js, poderíamos começar em example/js/ que gera os scripts example/jsm correspondentes.

Eu perdi alguma coisa?

Devemos depreciar a pasta de exemplos antes de fazer qualquer outra coisa

Não tenho certeza de quem é responsável por qualquer próxima etapa específica na pasta examples/js . A menos que possamos articular esse plano, prefiro que isso não bloqueie a conversão de coisas para classes ES. Por esse motivo, discordo um pouco de https://github.com/mrdoob/three.js/issues/11552#issuecomment -592768708. 🙂

além disso, parece que estamos apenas esperando uma data para ser definida

Além disso, como parte de uma revisão que fiz, encontrei este comentário sobre como outros recursos do ES2015 podem ser introduzidos por meio do processo de compilação de rollup atual. Há até um exemplo dado .

edit: aqui está a essência de outro exemplo rápido

Vamos iniciar o trem de conversão .
Comentário de dependências de arquivo .

@DefinitelyTalvez eu tenha algum tempo e adoraria ajudar. Posso levar alguns itens da lista dependencies.json ?

👍

vamos chamar a atenção sobre as coisas

@DefinitelyMaybe Qual é a melhor maneira de lidar com a herança de um ancestral profundo como Object3D ? Por exemplo, eu encontrei uma quebra ao converter src/audio/AudioListener.js :

[ROLLUP] bundles src/Three.js → build/three.js...
[ROLLUP] (!) Error when using sourcemap for reporting an error: Can't resolve original location of error.
[ROLLUP] src/audio/AudioListener.js: (137:1)
[ROLLUP] [!] Error: 'return' outside of function
[ROLLUP] src/audio/AudioListener.js (137:1)
[ROLLUP] 135:   };
[ROLLUP] 136: 
[ROLLUP] 137:   return AudioListener;
[ROLLUP]        ^
[ROLLUP] 138: }(Object3D));
[ROLLUP] Error: 'return' outside of function

íamos fazer uma anotação no topo do arquivo sobre quaisquer problemas que encontrarmos, se estou lembrando corretamente.

Eu não entendi o que estava acontecendo com AudioListener... Após alguma depuração, acho que há um problema de correspondência na transformação bubleCleanup . Consulte https://github.com/mrdoob/three.js/pull/19934#issuecomment -667411997 para obter mais informações. Eu me deparei com isso com algumas classes diferentes, então provavelmente teremos que resolver isso antes de ir muito mais longe.

este será o caso de alguns dos arquivos, mas não de todos. Estávamos antecipando tal problema.

Para aqueles que estão acompanhando, por favor, leia rapidamente a discussão aqui .

Enquanto isso, aposte em src/loaders !