Three.js: ES6 클래스 평가

그래서 당신은 대신 이 패턴을 사용하는 것을 제안하고 있습니까?

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

class PointLight extends Light

히히 😄 그리고 문제없...

@sasha240100 언젠가...

@mrdoob 은 정확하지 않습니다. 언급한 두 가지 방법은 직접적으로 동일합니다. OP가 비교되는 것 같아요

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

~와 함께

function PointLight () { ... };

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

PointLight.prototype.constructor = PointLight;

PointLight.prototype.prop1 = 'something';

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

...

예를 들어 여기 에서 수행되는 방식입니다.
내가 볼 수있는 한 이러한 스타일은 동일합니다. 누락 된 것이 있습니까?
아니면 Object.Assign 가 사용 가능해지고 코드베이스 전체에서 업데이트되지 않으면 스타일이 변경되었습니까?

@looeee @bfred-it @mrdoob 그냥 rollup-babel 를 사용하지 않는 이유는 무엇입니까?

비교 :
현재의. 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+. 코드는 동일하지만 es2015+ with 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;
  }
}

three.js 코드를 단순화하는 ES6 기능:

• 기본 매개변수 값.
  
  
  
  • 이러한 코드 부분을 쉽게 대체할 수 있습니다.
  
  
• 속성 속기
  
  
  
  • 여기에서 사용할 수 있습니다
  
  
• 화살표 기능
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

저는 모두 ES2015+로 이동하는 것에 찬성합니다. 우리는 현재 가지고 있는 것과 유사한 코드를 출력하는 방법을 찾아야 하므로 모든 경우에 성능이 동일하게 유지됩니다.

수업과 관련하여 질문이 있습니다. Vector3.unproject 와 같은 메서드를 클래스 구문으로 어떻게 옮기나요? 이 메서드는 실제로 새 범위를 만들기 위해 클로저를 사용합니다. 이것은 개체 생성의 양을 가능한 한 적게 유지하는 중요한 메커니즘입니다.

이 경우 Object.assign 가 필요합니까?

@Mugen87 @mrdoob es6 성능에 대한 흥미로운 정보입니다. 특히 Object.assign :

이 기사 에서

Vector3.unproject와 같은 메서드를 클래스 구문으로 어떻게 옮기나요? 이 메서드는 실제로 새 범위를 만들기 위해 클로저를 사용합니다.

@ Mugen87 그냥 내보내지 않은 모듈 범위 개체가 될 수 없습니까? 이 같은;

const tempMatrix = new Matrix();    

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

아 예, 이것이 작동해야한다고 생각합니다 😊

지난 달 이것은 트위터에서 제안되었습니다 .

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

@mrdoob 와우! 이미 작동하는 것 같습니다. 분기를 만들고 일부 클래스를 es6으로 변환하고 컴파일 방법을 볼 수 없습니까?

@satori99 전역 문제를 피하기 위해 Vector3 코드 안에 tempMatrix 를 유지하는 방법에 대한 아이디어:

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

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

@mrdoob 와우! 이미 작동하는 것 같습니다. 분기를 만들고 일부 클래스를 es6으로 변환하고 컴파일 방법을 볼 수 없습니까?

나에게 좋은 소리! 저는 현재 WebVR에 집중하고 있으므로 저와 다른 사람이 되어야 합니다.

@sasha240100 모듈 범위 vars를 사용하는 이점은 임시 변수에 적합한 것처럼 보이는 일반 사용자 코드에서 숨겨져 있다는 것입니다.

나는 private vars와 관련하여 "We are all Adults here"라는 파이썬적 접근 방식에 신경 쓰지 않지만 임시 변수는 실제로 네임스페이스를 불필요하게 오염시키지 않아야 합니다.

또한 브라우저에서 기본 모듈 지원을 활성화한 사용자가 src 파일을 직접 로드할 수 있다면 좋을 것입니다. 이것은 감시자가 필요 없고 편집할 때마다 트랜스파일할 필요 없이 훨씬 더 즐거운 개발 방법입니다. 클래스 속성을 사용하면 현재 클래스 사양의 일부가 아니므로 이것이 불가능합니다.

끼어들어서 죄송합니다. 이제 스레드가 완전히 다른 것으로 변경되었으므로 문제 제목을 "Evaluate ES6 classes"와 같은 것으로 변경해야 합니다.

@Mugen87 @satori99 패턴을 변경하는 이유는 무엇입니까?

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

typescript를 시도하지 않는 이유는 다른 버전의 js로 컴파일할 수 있습니다.

TypeScript 는 트랜스파일러 + 유형 검사기이자 JavaScript의 상위 집합이기 때문에 생각해 볼 수 있는 훌륭한 옵션이 될 것입니다. 따라서 코드 기반을 .ts 파일로 옮기고 유형 검사를 통해 ES6으로 점진적으로 리팩토링하는 것이 쉽습니다.

TypeScript를 사용해 본 적이 없다면 무섭게 들릴 수 있지만 실제로는 큰 학습 곡선이 아니며 가져올 이점에 대해 지불하기에는 적은 비용이 될 것입니다. TypeScript 커뮤니티는 이 전환을 돕고 현재 라이브러리에 대한 성능 테스트를 생성하여 다운그레이드되지 않았는지 확인하게 되어 매우 기쁩니다.

몇 가지 유용한 기사:

• TypeScript를 두려워하지 말아야 하는 이유
• TypeScript 대 ES6 대 ES2015
• TypeScript가 이겼습니다.
• TypeScript란 무엇이며 Anders Hejlsberg와 함께 사용하는 이유

핵심 개발자 Anders Hejlsberg의 말을 인용하자면 TypeScript는 JavaScript가 대형 애플리케이션에 적합하지 않다는 클라이언트 및 내부 팀의 불만에 대한 응답으로 탄생했습니다.

목표는 개방형 표준 및 크로스 플랫폼이라는 이점을 희생하지 않으면서 "클래스, 모듈 및 정적 유형과 같은 것으로 JavaScript를 강화"하는 것이었습니다. 그 결과 언어의 상위 집합으로 구축된 "애플리케이션 규모의 자바스크립트 개발을 위한 언어"가 탄생했습니다.

브라우저가 기본적으로 TypeScript를 실행할 수 있을 때까지 저는 JavaScript를 계속 사용하는 것을 선호합니다.

@mrdoob

TypeScript를 브라우저에서 직접 실행할 수 없다는 이유만으로 TypeScript를 사용하지 않는 유효한 이유라고 볼 수 없습니다. 컴파일 시간 검사만을 위한 모든 추가 코드 라인 때문에 브라우저에서 실행되는 것을 원하지 않을 것입니다. 현재 런타임 검사 언어가 아닙니다. 따라서 브라우저에서 사용한 적이 있다면 성능에 영향을 미치고 이것이 바닐라 JavaScript 코드가 되기 때문에 모든 입력된 코드가 제거될 가능성이 높습니다.

입력된 언어를 사용하는 요점과 대규모 코드 기반에서 개발할 때 얻을 수 있는 이점을 완전히 놓치고 있다고 생각합니다. 여전히 JavaScript를 작성하고 사용하고 있습니다. TypeScript의 요점은 JavaScript의 상위 집합이라는 것입니다. 컴파일러 옵션에서 구성할 수 있는 지정된 ECMAScript 대상 버전에서 JavaScript로 컴파일된 유형이 있는 JavaScript를 작성합니다. 허용되는 값은 'es3', 'es5', 'es2015', 'es2016', 'es2017' 또는 ' 이스넥스트'.

Typescript는 JavaScript이기 때문에 한 번에 모든 것을 리팩토링해야 하는 번거로움 없이 점진적으로 마이그레이션할 수 있습니다. 커뮤니티에서 점진적으로 수행하고 개선할 수 있습니다. ES6 클래스를 사용하기 위한 리팩토링과 함께 여기에서 논의되는 것보다 더 많은 작업이 필요하지 않습니다. 그것이 내가 새로운 문제를 여는 대신에 여기에서 언급하는 유일한 이유입니다.

좋은 예는 아래 TypeScript 플레이그라운드 링크를 참조하세요.

• 클래식 자바스크립트 예제
• 유형 추가 예
• 오류가 있는 유형 추가 예
• 클래스 사용 예
• 오류가 있는 클래스 사용 예제

@joejordanbrown

타이프스크립트가 이 특정 문제에 대한 최상의 솔루션이라는 점에 대해 당신과 동의하지 않을 수 있는 사람을 생각할 수 있습니까?

Google에 typescript vs 를 입력하면 몇 가지 용어가 나타나며 그 중 하나가 Flow입니다. 그것을 검색하면 사람들이이 두 가지의 장단점을 토론하는 많은 기사가 나오는 것 같습니다.

이러한 유형 중 하나를 선택하는 것보다 더 절충안으로 보이는 유형은 없습니다.

그들이 만든 결과보다 더 복잡한 프로젝트를 위해 Typescript를 저장하십시오. 특히 처음에는 HTML로 구현될 수 있었던 프론트엔드 프레임워크입니다. 내 원래 요점은 JavaScript 질병을 악화시키는 것이 아니라 제거하는 것이 었습니다. JavaScript는 three.js와 같은 복잡한 결과에 때때로 사용되는 거의 장난감에 가까운 간단한 언어입니다. Typescript는 무의미합니다.

2017년 9월 6일 오후 1시 55분에 Joe [email protected] 에서 다음과 같이 썼습니다.

@mrdoob

TypeScript를 브라우저에서 직접 실행할 수 없다는 이유만으로 TypeScript를 사용하지 않는 유효한 이유라고 볼 수 없습니다. 컴파일 시간 검사만을 위한 모든 추가 코드 라인 때문에 브라우저에서 실행되는 것을 원하지 않을 것입니다. 현재 런타임 검사 언어가 아닙니다. 따라서 브라우저에서 사용한 적이 있다면 성능에 영향을 미치고 이것이 바닐라 JavaScript 코드가 되기 때문에 모든 입력된 코드가 제거될 가능성이 높습니다.

입력된 언어를 사용하는 요점과 대규모 코드 기반에서 개발할 때 얻을 수 있는 이점을 완전히 놓치고 있다고 생각합니다. 여전히 JavaScript를 작성하고 사용하고 있습니다. TypeScript의 요점은 JavaScript의 상위 집합이라는 것입니다. 컴파일러 옵션에서 구성할 수 있는 지정된 ECMAScript 대상 버전에서 JavaScript로 컴파일된 유형이 있는 JavaScript를 작성합니다. 허용되는 값은 'es3', 'es5', 'es2015', 'es2016', 'es2017' 또는 ' 이스넥스트'.

Typescript는 JavaScript이기 때문에 한 번에 모든 것을 리팩토링해야 하는 번거로움 없이 점진적으로 마이그레이션할 수 있습니다. 커뮤니티에서 점진적으로 수행하고 개선할 수 있습니다. ES6 클래스를 사용하기 위한 리팩토링과 함께 여기에서 논의되는 것보다 더 많은 작업이 필요하지 않습니다. 그것이 내가 새로운 문제를 여는 대신에 여기에서 언급하는 유일한 이유입니다.

예제는 TypeScript 플레이그라운드 링크를 참조하세요.

클래식 자바스크립트 예제
유형 추가 예
오류가 있는 유형 추가 예
클래스 사용 예
오류가 있는 클래스 사용 예제
—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

^ 일관성이 있는 한 괴물 같은 패턴도 괜찮을 것입니다.

@joejordanbrown 은 당신이 typescript와 사랑에 빠진 것처럼 들립니다. 자유롭게 프로젝트를 포크하고 타이프스크립트로 이식하세요. 쓰리.티! 🙌

@pailhead

그것은 선택의 문제입니다. 많은 사람들이 동의하고 동의하지 않을 것이라고 확신합니다. 그것이 정상이지만 정상입니다! 당신은 항상 "이것 대 저것", "내 것이 당신보다 낫다"는 것을 보게 될 것입니다. 각자 장단점이 있는걸로 압니다. 사용 가능한 옵션을 평가하고 프로젝트에 도움이 될 수 있는지 확인하는 것입니다. 비교는 좋은 일이며 프로젝트를 더욱 발전시킵니다.

당신은 Flow를 언급했는데, 내가 볼 수 있는 문제는 다음과 같습니다.

• Flow 라이선스는 BSD 3절 " Facebook BSD + Patents License "이며 Apache Software Foundation은 새 프로젝트에서 이 라이선스의 사용을 금지했습니다. 자세한 내용은 여기에서 읽을 수 있습니다.

• TypeScript에 비해 IDE 지원이 부족합니다.

• TypeScript에 비해 사용자 기반이 적고,

• 공개 라이브러리에 사용 가능한 타이핑은 불완전하고 TypeScript에는 잘 관리된 타이핑이 많이 있습니다.

• 문서 및 리소스는 찾기 어렵고 TypeScript에 비해 모호합니다. 훌륭한 문서, 책, 비디오 및 기타 많은 전자 학습 리소스를 찾을 수 있습니다.

• Flow는 // @flow 플래그가 지정된 .js 파일을 사용합니다. .js 확장자가 표시되므로 혼동될 수 있으므로 JavaScript를 예상하지만 실제로는 FlowType입니다. TypeScript는 자체 확장자를 사용하므로 .ts . 이것은 또한 동일한 디렉토리에 동일한 이름을 가진 TypeScript 및 JavaScript 출력 파일을 가질 수 있도록 합니다. 이는 소규모 프로젝트에 이상적입니다. 분명히 큰 프로젝트에서는 그렇지 않을 것입니다. 빌드 프로세스를 관리하는 시스템.

Google조차도 TypeScript를 크게 지원하고 있습니다. 이는 TypeScript에 대한 확신을 보여줍니다. 여기 또는 여기 에서 게시물을 읽으십시오.

Typescript는 2017년 3월부터 무제한 클라이언트 개발이 허용되었습니다. TypeScript의 TypeScript 및 Angular는 Google 애널리틱스, Firebase, Google Cloud Platform 및 버그 추적, 직원 리뷰, 제품 승인 및 출시 도구와 같은 중요한 내부 도구에서 사용됩니다.

Typed 언어 사용에 대한 토론을 열고 다른 사람들이 이 아이디어에 대해 어떻게 생각하는지 살펴봐야겠습니다. @mrdoob 은 아이디어에 대해 논의하는 것조차 완전히 반대하는 것 같습니다.

@arctwelve
이 프로젝트가 복잡하지 않고 Typed 언어를 사용하는 것이 어떻게 부정적인 영향을 미치는지 모르겠습니다.

@mrdoob
전혀 그렇지 않습니다. 특히 ES6 클래스로 업데이트하기 위해 새 분기가 생성되는 경우에 얻을 수 있는 이점을 알 수 있습니다. three.ts라고 하는 자신만의 포크를 만들어 대답하는 것은 어리석은 일이라고 생각합니다. 모든 사람이 1개의 프로젝트에 집중하고 최선을 다하는 대신 OSS 프로젝트를 포크하고 자신의 소스 코드를 수정했다면 좋은 OSS 관행에 반하는 것입니다. 어떤 이유에서든 그들이 선호하는 프로젝트에 집중하고 집중하는 정말 열악한 소프트웨어나 커뮤니티로 끝날 것입니다. 장점과 단점에 대해 공개 토론을 할 수 없는 이유는 무엇입니까?

악마의 변호인 역할을 하려는 것은 아니지만, 그가 한 것처럼 보입니다.

열린 토론을 하다

정말 짧았어요 :)

저도 비슷한 관점을 공유합니다. 그것은 JS 라이브러리이고 JS는 표준화되어 있습니다. JS 라이브러리용으로 JS를 선택하는 것은 잘못될 수 없지만 다른 것을 선택하면 할 수 있습니다. 저는 Flow를 typescript의 대안 중 하나로 선택했습니다. 다른 것이 있는지는 모르겠습니다.

어쨌든 우리는 정말 주제에서 벗어난 것 같습니다.

Mugen87에서 제목을 변경했습니다.
ES6 클래스를 평가 하기 위해 JavaScript 질병 제거

원래 제목은 스타일 일관성의 부족에 대해 (내가 이해하는 한) 언급했습니다. 특히 어떤 곳에서는 Object.assign() 를 사용하고 다른 곳에서는 다른 패턴을 사용합니다.
내가 여기에서 평가하는 것이 있다면 그것은 문제의 현재 제목이 될 것입니다. 일관성 문제가 새로운 언어 사용에 대한 논의로 승격되는 이유는 무엇입니까?

저는 typescript와 es6 모두에서 코드가 상당히 일관성이 있어야 한다고 생각합니다.

이 페이지를 업데이트하여 이 문제를 해결하겠습니다.

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

다음 중 하나를 추가합니다.

A) "...Object.assign 사용 ..."
B) "...Object.assign을 사용하지 마십시오"

라이브러리 전체에 걸쳐 하나의 스타일. 변경할 필요가 없습니다.

예를 들어 Materials 클래스에 있는 충실한 두 줄 스타일은 훨씬 더 명확하고 깔끔합니다.

첫글에 있습니다.

나는 제안한다:

1. 이 문장을 반영하도록 제목을 편집하고, 라이브러리 전체에 하나의 스타일을 갖는 것에 대해 논의하고, 스타일 가이드를 편집하는 등.
2. es6 클래스가 평가될 "es6 클래스 평가"라는 제목의 새 토론 시작
3. "입력된 언어로 작성된 3가지 평가"라는 제목의 새 토론 시작

어쨌든 우리는 정말 주제에서 벗어난 것 같습니다.

물론. @joejordanbrown TypeScript 에 대해 논의할 새 주제를 자유롭게 작성하십시오.

Btw, 이전 대화를 무시하는 것도 나쁜 OSS 관행입니다... https://github.com/mrdoob/three.js/issues/341#issuecomment -47000692

주제로 돌아갑니다. 나는 우리가 이미 이 문제를 해결했다고 생각합니까?

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

시도해 볼 사람이 필요합니다.

자, 그럼... 우선

첫 번째 패턴(최고의 IMO):

function MyClass() {...}

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

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

두 번째 패턴:

function MyClass() {...}

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

MyClass.prototype.constructor = PointLight;

MyClass.prototype.prop1 = 'something';

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

...

@arctwelve 이 패턴은 여러 가지 이유로 도입되었습니다. 이것은 자위 행위가 아닙니다!

무엇보다 먼저 객체 상속에 대해 명확하게 읽을 수 있습니다. Object.assign 는 여기에 개체 상속에 대한 내용이 분명히 있습니다. 그러면 MyClass.prototype 의 많은 줄에서 상속된 개체를 잃을 수 없습니다.
둘째, 다중 상속의 경우 이것은 훨씬 더 명확합니다.
셋째, 클래스의 생성자는 읽을 수 있고 첫 번째 포인트처럼 많은 라인에서 손실되지 않습니다.
넷째, 동일한 파일에 3, 4, 5... 등의 클래스가 있을 때 훨씬 더 명확하게 동일한 위치(괄호 ​​안)에서 속성과 메서드를 그룹화할 수 있습니다.
다섯째, 이 패턴을 사용하면 일부 "상속" 속성에 대해 올바른 복사본을 확인할 수 있습니다.

마지막으로( @looeee ) 이것은 성능을 위한 것이기도 합니다. 첫 번째 버전은 프로토타입을 여러 번 호출하는 대신 파일 구문 분석이 발생할 때 더 최적화됩니다.

어쨌든 !

이제 ES6 구문으로 전달해야 합니다!

@mrdoob

나에게 좋은 소리! 저는 현재 WebVR에 집중하고 있으므로 저와 다른 사람이 되어야 합니다.
시도해 볼 사람이 필요합니다.

es6 브랜치를 만드시겠습니까? 아니면 우리 자신의 것입니까?

첫 번째 버전은 프로토타입을 여러 번 호출하는 대신 파일 구문 분석이 발생할 때 더 최적화됩니다.

당신은 그것에 대해 확신합니까? 나는 Object.Assign 가 더 느릴 것으로 예상합니다. 그러나 두 경우 모두 걱정할 성능 오버헤드가 충분한지 의심스럽습니다.

절대적으로: https://jsperf.com/inline-prototype-vs-assign-prototype/1

크롬 버전 61.0.3163.100(Build officiel)(64비트)에서 할당된 프로토타입은 약 60% 더 빠릅니다.

흥미로운. 테스트를 해주셔서 감사합니다.

그 결과가 모든 브라우저에 적용되는 것은 아닙니다. Firefox에서는 거의 동일합니다( Object.Assign ~3% 더 빠름). 반면 Edge에서는 Object.Assign ~33% 더 느립니다 .

그러나 어쨌든 나는 이것이 어떤 스타일이 더 나은지에 대한 논쟁과 관련이 있다고 생각하지 않습니다. 가장 느린 전체(Chrome의 인라인 프로토타입)조차도 여전히 초당 180,000번 이상의 작업으로 실행되고 있으며 아마도 몇 천 번의 작업이 있을 것입니다. 이러한 설정은 코드에서 수행됩니다. 여기서 우리는 아마도 몇 밀리초의 차이에 대해 이야기하고 있는 것 같습니다.

저에게는 Object.Assign 스타일이 더 깔끔하고 읽기 쉬우며 이것이 찬성하는 주요 주장입니다.

예, 이것은 파일당 약 몇 밀리초이며 파일이 자바스크립트 엔진에 의해 처음으로 구문 분석될 때만 발생합니다... 그러나 threejs와 같은 큰 라이브러리의 경우 페이지 로드 시 이득이 합리적으로 약 200밀리초일 수 있습니다.
더 이상 기다릴 수 없는 전면 사용자를 위한 3scd의 제한을 잊지 마세요!

나는 threejs로 Angular 프로젝트를 만들려고하는데 항상 threejs의 모든 부분을 해킹하는 것처럼 보입니다.
우선 OrbitalControls가 필요한 경우와 같이 존재해야 하는 3개의 상수가 있는 es5 구문입니다.
threejs 타이핑이 있지만 동일한 패키지에 있는 것이 더 편리합니다. 타이핑에는 OrbitalControls가 있지만 import { OrbitalControls } from 'three; 처럼 단순히 가져올 수는 없습니다.
Webpack에는 트리 쉐이킹이 있으므로 es6의 경우 필요한 모든 것을 하나의 프로젝트에 포함하고 분리된 프로젝트로 옮기지 않도록 할 수 있습니다.
@mrdoob 그래서 Typescript가 그렇게 나쁜 이유는 무엇입니까? 어쨌든 타이핑이 있는 모든 버전의 ES로 컴파일됩니다.
React와 같은 다른 많은 프레임워크에서도 사용됩니다.

@FriOne @mrdoob 이 정말로 Typescript가 나쁘다고 생각하는지 확실하지 않지만 그는 이 스레드의 주제가 아니기 때문에 이 문제/스레드에서 Typescript에 대해 논의하는 것을 반대한다고 생각합니다. ES6 클래스는 Typescript에 대해 또는 Typescript에 대해 작동하지 않는다고 생각합니다. 코드베이스를 ES6으로 변환하면 구문이 매우 유사하기 때문에 코드베이스를 Typescript로 이식하는 것이 훨씬 쉽습니다. 예, Typescript가 많은 새로운 옵션을 활성화할 수 있다고 생각합니다. 예를 들어, 더 최적화된 코드를 "트랜스파일"하는 데 도움이 될 수 있고, 새로운 개발자가 라이브러리를 더 빨리 배우는 데 도움이 될 수 있으며, 아마도 https://github.com/AssemblyScript/assemblyscript와 같은 미래에 실험을 위한 문을 열 수 있습니다. Typescript @joejordanbrown 이 장단점을 자세히 설명해주셔서 많은 장점이 있다고 생각합니다.

하지만 다시 주제로 돌아가서: 제 생각에는 ES6 클래스를 채택하는 것이 한 단계 더 나아가고 나서 Typescript에 대해 논의할 수 있다고 생각합니다. 그러니 한걸음 한걸음 나아가자

@tschoartschi , typescript가 es6 클래스로의 마이그레이션 및 기타 리팩토링에 도움이 될 수 있다고 생각합니다. 저는 그런 마이그레이션 경험이 없어서 틀릴 수도 있습니다.

@FriOne 그것은 의존합니다 😉 물론 컴파일러가 모든 오류와 실수를 알려줄 수 있기 때문에 Typescript가 도움이 될 수 있지만 Typescript와 함께 작동하려면 먼저 전체 빌드 파이프를 설정해야 합니다. 또한 Typescript가 적합한지 여부를 평가해야 합니다. 먼저 ES6 클래스로 변환하고 나서 Typescript에 대해 생각하는 것이 좋다고 생각합니다.

안녕하세요, 우리는 코스의 오픈 소스 프로젝트에 기여하고자 하는 KTH의 5명의 학생 그룹이며 프로젝트의 일부를 새로운 ES6 구문으로 변환하려고 합니다.

나는 개념 증명으로 몇 가지 예제와 함께 Three.js를 TypeScript에 포팅했습니다(r82).

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

TypeScript 소스가 즉석에서 트랜스파일되기 때문에 예제를 로드하는 데 약간의 시간이 걸립니다. 변환된 JavaScript를 사용할 때 원본만큼 빠르게 로드됩니다.

three.js가 typescript로 이식되는 것을 보고 싶습니다. 다음 웹 세대를 위해 시간의 시험을 견디려면 프로젝트를 현대화해야 한다고 생각합니다. 언젠가는 AssemblyScript와 함께 작동하고 WASM에서 실행되는 것을 볼 수도 있습니다. threejs가 아니라면 분명히 다른 것이 있을 것입니다.

@WestLangley 및 @mrdoob 이 완료되었습니다.

@bhouston 여기서 결론은 무엇입니까?

@pkieltyka 예 또한 TypeScript가 Three.js와 같은 라이브러리에 적합하다고 생각합니다. 모든 기술 전문가 외에도 라이브러리 사용을 용이하게 하고 초보자가 API를 탐색하는 데 도움이 됩니다. 하지만 ES6의 모든 것을 먼저 끝내고 TypeScript를 고려하는 것도 중요하다고 생각합니다. 최신 JavaScript에서는 TypeScript 형식으로 유형을 추가하는 것이 그리 복잡하지 않다고 생각합니다.

@flyover 역시 TypeScript 버전의 Three.js에 대한 개념 증명을 참조하세요. Three.js 관리자로부터 피드백을 받았습니까?

three.js에 대한 typescript도 지원합니다. typescirpt는 기본적으로 최고입니다.
연습과 원시 JavaScript는 더 이상 없습니다.

2019년 1월 5일 토요일 오전 4시 13분 tschoartschi < [email protected] 작성:

@pkieltyka https://github.com/pkieltyka 예 TypeScript도 생각합니다.
Three.js와 같은 라이브러리에는 많은 의미가 있습니다. 모든 옆에
기술적인 장점 또한 라이브러리 사용을 용이하게 하고 초보자를 돕습니다.
API를 탐색합니다. 하지만 ES6를 모두 끝내는 것도 중요하다고 생각합니다.
먼저 물건을 만들고 TypeScript를 고려하십시오. 최신작부터 생각합니다
JavaScript TypeScript의 형식으로 유형을 추가하는 것은 그리 복잡하지 않습니다.

@flyover https://github.com/flyover 좋네요.
Three.js의 TypeScript 버전. 유지 보수로부터 피드백을 받았습니까?
Three.js?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451639995 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAj6_bkdND7I0_F4AJcBV0DYLpToUIVhks5vAGykgaJpZM4N9vH8
.

@bhouston TypeScript가 훌륭한 기술이라는 데는 동의하지만 당신이 했던 방식으로는 그렇게 하지 않을 것입니다. 나는 우리가 항상 원시 JavaScript에 최대한 가깝게 유지하고 맨 위에 TypeScript 기능을 추가해야 한다고 생각합니다. TypeScript는 JavaScript 사양을 매우 밀접하게 따르기 때문에 TypeScript는 실제로 유형이 있는 ES6처럼 읽습니다.

three.js와 같은 라이브러리의 경우 TypeScript는 정말 유용할 수 있으며 점진적으로 채택될 수 있습니다. 따라서 우리는 특히 모든 ES6 리팩터가 완료된 후에 "빅뱅" 재작성을 필요로 하지 않을 것입니다.

TypeScript에 대한 @mrdoob 의 입장이 변경되었는지 듣는 것도 흥미로울 것입니다. TypeScript는 "typed JavaScript"에 대한 "사실상" 표준이 된 것 같습니다(이것은 확실한 사실이 아니기 때문에 내 주장을 아포스트로피 아래에 두었습니다)

첫 번째 단계는 ES6 기능, 특히 클래스, 화살표 기능, 'let' 및 'const'를 채택하는 것입니다.

@roomle-build가 지적한 것처럼 우리가 결정하면 ES6 코드 위에 점차적으로 타이프스크립트 기능을 점진적으로 추가하는 것이 쉽기 때문에 완료되면 타이프스크립트 지원에 대해 적절하게 논의할 수 있습니다.

한 번에 두 가지를 모두 수행하면 일이 너무 복잡해 질 것 같습니다.

TypeScript가 미래의 어느 시점에서 옵션이 될 수 있다는 소식을 듣게 되어 기쁩니다 :-) 아마도 @flyover 가 수행한 작업 중 일부를 재사용할 수 있을 것입니다.

하지만 @looeee 의 말에 전적으로 동의합니다. 먼저 모든 ES6 작업을 완료하고 다음 단계에 집중하세요.

모든 ES6 작업을 완료하십시오

우리가 적어도 시작할 수 있다면 기쁠 것입니다 😅

TypeScript의 좋은 중간 단계는 모든 JavaScript 파일 옆에 유형 파일을 추가하는 것입니다. 따라서 다음 두 가지가 모두 있을 수 있습니다.

벡터3.js
Vector3.d.ts

이것은 사이드카 파일로서 TypeScript의 모든 이점을 제공합니다.

지금은 @types/three 파일이 있지만 구식이며 별도로 유지 관리되므로 항상 데이터가 부족합니다.

Three.JS의 주요 경쟁자는 Babylong이며 완전한 타이프스크립트이며 이 점에서 이점이 있다고 생각합니다.

그러나 @types/three를 죽이고 사이드 카 유형 정의 파일로 Three right에 통합하는 것은 훌륭한 첫 번째 단계가 될 것입니다.

우리는 또한 어떤 종류의 트리 쉐이킹과 함께 모든 예제를 /src에 통합해야 합니다.

현재 Three.JS의 코드 구조는 2014년이므로 작업하기가 어렵습니다.

모든 예시?

예제/js

2019년 1월 7일 월요일 오전 10시 25분 Dusan Bosnjak < [email protected] 작성:

모든 예시?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
.

@보스턴

TypeScript의 좋은 중간 단계는 모든 JavaScript 파일 옆에 유형 파일을 추가하는 것입니다. 따라서 다음 두 가지가 모두 있을 수 있습니다.

벡터3.js
Vector3.d.ts

.d.ts 파일이 c에서 .h 파일로 작동합니까?

.d.ts 파일이 c에서 .h 파일로 작동합니까?

아주 좋은 비유입니다. 흥미로운 사람이 이미 여기에서 대부분의 작업을 수행했습니다. https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/three 따라서 실제로는 이러한 유형 파일의 소유권을 가져 와서 Three.js에 통합하는 것입니다. 원한다면 이것을 Three.js에 통합하고 적절하게 분할하는 PR을 만들 수 있습니다.

Typescript의 인기도를 확인하려면 주당 @Types/three가 다운로드되는 횟수를 확인하세요.

https://www.npmjs.com/package/@types/three - 주당 63,000 다운로드.

인상적인!

원한다면 이것을 Three.js에 통합하고 적절하게 분할하는 PR을 만들 수 있습니다.

나에게 좋은 소리 👍

eslint와 유사한 명령줄 검사를 실행하여 유형 파일과 소스 .js 파일이 정렬되도록 할 수 있습니까? d.ts 파일의 소유권을 가져간다면 파일이 일치하는지 정기적으로 확인할 수 있는 방법을 사용하는 것이 좋습니다.

Typescript의 인기도를 확인하려면 주당 @Types/three가 다운로드되는 횟수를 확인하세요.

https://www.npmjs.com/package/@types/three - 주당 63,000 다운로드.

Visual Studio Code의 자동 유형 획득 기능을 통해 Visual Studio Code를 사용할 때 자동으로 발생하기 때문에 Visual Studio Code의 인기에 더 큰 기여를 했습니다.
즉, 무시할 수 없습니다.

@flyover @bunnybones1 @mrdoob @looeee @donmccurdy @bhouston @roomle-build @pkieltyka @FriOne @joejordanbrown 여러분 모두 TypeScript에 관심이 있는 것 같으니 TypeScript와 관련된 새로운 문제를 만들었습니다. 모든 TS 토론을 그곳으로 옮기는 것이 합리적이라고 생각합니다. 관심이 있으시면 여기에서 찾을 수 있습니다: https://github.com/mrdoob/three.js/issues/15545

ES6 클래스로 이식하는 데 시간을 할애할 용의가 있습니다. 이것이 언젠가 Typescript를 지원하기 위한 좋은 브리지 솔루션이 될 것이라고 생각합니다.

첫 번째 단계는 일부 추가 기능을 ES6으로 변환하는 것입니다.

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

컨트롤, 로더 및 내보내기가 좋은 후보입니다. 언제든지 도와주세요!

@mrdoob 확인을 위해 ES 모듈로 변환하지만 아직 다른 ES6 기능을 사용하지 않는다는 것을 의미합니까?

나는 그 변환을 수행하는 과정이 다음과 같다고 가정한다:

1. moduleize.js 스크립트를 사용하여 원본 파일을 ES 모듈로 변환합니다.
2. 필요한 경우 문제를 정리합니다.
3. 어떤 시점(이 릴리스 또는 가까운 장래에)에서 rollup-examples.config.js 를 사용하여 ES 모듈을 UMD 모듈로 변환하기 시작할 것입니다. 이때 examples/js 의 버전은 손.
4. 일단 안정화되면 ES6 기능 도입과 같은 다른 변경 사항을 고려할 수 있습니다.

@mrdoob 확인을 위해 ES 모듈로 변환하지만 아직 다른 ES6 기능을 사용하지 않는다는 것을 의미합니까?

네, 죄송합니다. 지정했어야 했습니다.

나와 @bhouston 은 대부분의 Three.JS 프로젝트에 *.d.ts 파일을 제공하는 약속된 PR을 만들었습니다. https://github.com/mrdoob/three.js/pull/15597

ES6 클래스와 Typescript 정의를 기다릴 수 없습니다. three.js로 작업할 때마다 액세스할 수 없는 범위에 있는 하나의 기능을 다시 구현하기 위해 수백 개의 코드 줄을 복사하여 붙여넣어야 합니다. 장면을 최적화해야 하는 경우 실제로는 우아한 작업 방식이 아닙니다. 마침내 기능을 확장하고 재정의할 수 있도록 워크플로를 새로운 수준으로 끌어올릴 것입니다.
따라서 클래스 기능을 최소한 "보호"하고 예외 없이 액세스할 수 있도록 해주세요 🤗

three.js로 작업할 때마다 액세스할 수 없는 범위에 있는 하나의 기능을 다시 구현하기 위해 수백 개의 코드 줄을 복사하여 붙여넣어야 합니다. ... 따라서 클래스 기능을 최소한 "보호"하고 예외 없이 액세스할 수 있도록 하십시오.

@dionysiusmarquis 여기서 무슨 말인지 잘 모르겠습니다... 기존 TS 입력에 사용하려는 기능이 비공개로 잘못 표시되어 있나요? 아니면 현재 프로토타입 스타일의 클래스 정의가 TS에서 사용하기 어려운가요? 예를 공유할 수 있습니까?

three.js로 작업할 때마다 액세스할 수 없는 범위에 있는 하나의 기능을 다시 구현하기 위해 수백 개의 코드 줄을 복사하여 붙여넣어야 합니다. ... 따라서 클래스 기능을 최소한 "보호"하고 예외 없이 액세스할 수 있도록 하십시오.

@dionysiusmarquis 여기서 무슨 말인지 잘 모르겠습니다... 기존 TS 입력에 사용하려는 기능이 비공개로 잘못 표시되어 있나요? 아니면 현재 프로토타입 스타일의 클래스 정의가 TS에서 사용하기 어려운가요? 예를 공유할 수 있습니까?

특정 시나리오에 대한 특정 그림자 맵을 구현하고 싶었을 뿐입니다. 예를 들어 getDepthMaterial 를 재정의할 수 있으면 도움이 됩니다. 현재 내가 원하는 변경 사항을 포함하는 복사/붙여넣기 버전으로 빌드 프로세스에 내 자신의 WebGLShadowMap 를 삽입합니다.
모든 단일 three.js 클래스가 가능한 한 많이 노출된다면 정말 좋을 것입니다. typescript를 사용하면 의도한 목적을 설명하기 위해 함수를 private 또는 protected 로 쉽게 플래그 지정할 수 있습니다. 예를 들어 내 ES6 클래스/Typescript ShadowMap은 다음과 같습니다.

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 }

"낮은 수준" 클래스를 수정할 수 있다면 집처럼 느껴집니다.

수업과 관련하여 질문이 있습니다. Vector3.unproject 와 같은 메서드를 클래스 구문으로 어떻게 옮기나요? 이 메서드는 실제로 새 범위를 만들기 위해 클로저를 사용합니다. 이것은 개체 생성의 양을 가능한 한 적게 유지하는 중요한 메커니즘입니다.

이 경우 Object.assign 가 필요합니까?
@무겐87

이제 클래스로 클로저를 수행할 수 있습니다. 해당 구문 설탕을 탐색하는 방법이 명확하지 않습니다. StackOverflow에 대한 내 대답을 참조하십시오. https://stackoverflow.com/questions/39297258/iife-in-es6-class-literal/56077521#56077521 (나는 겸손해야 하며 작동 방식/이유를 완전히 이해하지 못한다는 것을 인정해야 합니다. .)

죄송합니다. 이 코드는 안티 패턴처럼 보이며 프로젝트에서 이를 적용해서는 안 됩니다. 모듈 범위에서 변수를 관리하기 위한 적절한 솔루션이 있습니다. 나는 이 길을 가는 것을 제안한다.

@Mugen87 네 저도 모듈 범위를 잘 활용해야 한다고 생각합니다. 이것은 나무를 흔드는 것과 같은 일에도 도움이 될 것입니다. 이것은 이미 다음과 같은 다른 많은 문제에서 논의되었습니다. https://github.com/mrdoob/three.js/issues/6241#issuecomment -398703521

죄송합니다. 이 코드는 안티 패턴처럼 보이며 프로젝트에서 이를 적용해서는 안 됩니다. 모듈 범위에서 변수를 관리하기 위한 적절한 솔루션이 있습니다. 나는 이 길을 가는 것을 제안한다.

문제 없어요. 가능성을 언급했을 뿐입니다. 진행 중인 더 나은/더 깨끗한 솔루션이 있다면 실행에 옮기고 싶습니다. Three.js 프로젝트(사용법, 소스, 토론 등)는 JS 지식의 주요 소스였습니다. 따라서 Three.js에 새롭고 더 나은 프로그래밍 패턴을 도입하면 나와 내 프로젝트에도 도움이 될 것입니다. 죄송합니다. ;-)

@Mugen87 내가 좀 더 배우고 이해할 수만 있다면 왜 class-IIFE를 안티 패턴으로 고려하는지 자세히 설명해 주시겠습니까? 모듈은 본질적으로 변수 범위를 지정하지만 이전에 코어가 구축된 방식과 다르지 않다는 것을 이해합니다. 그리고 캐시 변수를 사용하는 함수가 너무 많기 때문에 어떤 함수도 동시에 충돌하거나 변수를 사용하지 않는지 확인하는 것이 정말 중요할 것입니다. 함수 범위 지정을 통해 이를 관리 및 유지 관리하기가 더 쉬워지므로 안티 패턴으로 (적어도 모듈 범위에서 모든 캐시 변수를 던지는 것과 비교할 때).

클래스 IIFE를 안티 패턴으로 간주하는 이유에 대해 좀 더 자세히 설명해 주시겠습니까?

https://github.com/mrdoob/three.js/pull/14695에 언급된 것처럼 나무 흔들림을 잠재적으로 방해하는 접근 방식은 사용하지 않습니다. 게다가 전체 패턴이 해킹처럼 보입니다. 덜 "멋진" 접근 방식을 사용하는 것이 일반적으로 더 잘 작동합니다. 불필요한 클로저를 피하면 일반적으로 코드 실행 성능도 향상됩니다.

그리고 캐시 변수를 사용하는 함수가 너무 많기 때문에 함수가 충돌하거나 동시에 변수를 사용하지 않도록 하는 것이 정말 중요합니다.

IIFE는 주로 수학 수업에서 사용됩니다. 거기에 상당한 양의 테스트 커버리지가 있기 때문에( @gero3 는 최근에 더 많은 단위 테스트를 추가하여 훌륭한 일을 했습니다), 그것들을 강력하게 제거하는 것이 더 쉬울 것입니다.

IIFE를 제거하는 것이 좋습니다. 2013년에는 제가 책임이 있다고 생각합니다. 유지하기 힘든 정적 변수 패턴을 없애기 위해서였습니다. 이 PR에서 수행되었습니다.

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

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

그리고 여기에서 더 일찍 논의했습니다.

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

흥미로운 사실은 이것을 넣었을 때 코드 성능 차이가 없었습니다.

나는 그 변환을 수행하는 과정이 다음과 같다고 가정한다:

1. moduleize.js 스크립트를 사용하여 원본 파일을 ES 모듈로 변환합니다.
2. 필요한 경우 문제를 정리합니다.
3. 어떤 시점(이 릴리스 또는 가까운 장래에)에서 rollup-examples.config.js 를 사용하여 ES 모듈을 UMD 모듈로 변환하기 시작할 것입니다. 이때 examples/js 의 버전은 손.
4. 일단 안정화되면 ES6 기능 도입과 같은 다른 변경 사항을 고려할 수 있습니다.

야. 놓쳤을 수도 있지만 수업을 향한 우리의 점진적인 단계는 무엇입니까?

1. [x]modularize.js 스크립트를 사용하여 원본 파일을 ES 모듈로 변환합니다.
2. [x] 필요한 경우 문제를 정리합니다.
3. [ ] 어떤 시점(이 릴리스 또는 가까운 장래에)에서 우리는 ES 모듈을 UMD 모듈로 변환하기 위해 rollup-examples.config.js를 사용하기 시작할 것입니다. 이 시점에서 examples/js의 버전은 더 이상 손.
4. [ ] 일단 안정화되면 ES6 기능 도입과 같은 다른 변경 사항을 고려할 수 있습니다.

위의 단계에서 우리는 본질적으로 단계 (1)과 (2)를 완료했습니다.

(3) 우리는 더 이상 그런 식으로 하지 않고 대신 어느 시점에서 examples/js 폴더를 더 이상 사용하지 않고 제거합니다(https://github.com/mrdoob/three.js/pull/18749 참조). .

examples/jsm 에 ES6 클래스를 도입하는 (4) 단계는 examples/js 소스 버전에서 생성되지 않은 몇 가지 예제에서만 (현재로서는) 수행할 수 있다는 것을 의미 한다고 생각 합니다. examples/js 가 제거되면 나머지 작업을 수행할 수 있습니다.

^하지만 여기에서 줄 사이를 너무 많이 읽을 수 있습니다. @Mugen87 또는 @mrdoob 이 확인할 수 있습니까?

IMO에서 프로젝트는 모듈 전용 코드 기반을 달성하기 위해 examples/js 의 사용 중단 및 제거에 중점을 두어야 합니다. 다음 단계에서는 클래스 마이그레이션을 진행하는 것이 좋습니다. 예제로 시작한 다음 코어를 마이그레이션합니다.

완벽한. 감사 해요. 그 방법을 자세히 살펴볼 것입니다

닫힌 문제에서 다시 게시되었습니다.
안녕하세요,

클래스 마이그레이션을 어떻게 진행하고 싶은지에 대한 모든 사람의 생각을 알리고자 이 문제를 만들고 싶었습니다.

지금까지 내가 겪은 것에 대한 빠른 요약:

• 다른 작업을 수행하기 전에 examples 폴더를 더 이상 사용하지 않아야 합니다.
• 변환할 수 있는 예제에 의해 확장되지 않은 src/ 부분이 있습니다.
• moduleize.js 스크립트를 약간 변경하면 해당 examples/jsm 스크립트를 생성하는 examples/js/에서 시작할 수 있습니다.

내가 놓친 것이 있습니까?

다른 작업을 수행하기 전에 examples 폴더를 더 이상 사용하지 않아야 합니다.

examples/js 폴더의 특정 다음 단계에 대한 책임이 누구에게 있는지 잘 모르겠습니다. 우리가 그 계획을 명확히 할 수 없다면, 이것이 ES 클래스로의 변환을 막지 않았으면 합니다. 그런 이유로 나는 https://github.com/mrdoob/three.js/issues/11552#issuecomment -592768708에 다소 동의하지 않습니다. 🙂

더 나아가 우리는 날짜가 정해지기를 기다리고 있는 것 같습니다.

또한 내가 한 수정의 일부로 현재 롤업 빌드 프로세스를 통해 다른 ES2015 기능을 도입할 수 있는 방법에 대한 이 의견 을 찾았습니다. 주어진 예도 있습니다.

편집: 여기에 또 다른 빠른 예의 요지 가 있습니다.

변환 열차를 시작하겠습니다 .
파일 종속성 주석 .

@Definitely아마도 나는 시간이 있고 돕고 싶습니다. dependencies.json 목록에 있는 일부 항목을 가져갈 수 있습니까?

👍

일에 대해 dibs를 부르자

@DefinitelyMaybe Object3D 와 같은 깊은 조상의 상속을 처리하는 가장 좋은 방법은 무엇입니까? 예를 들어 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

내가 올바르게 기억한다면, 우리가 겪는 모든 문제에 대해 파일 상단에 메모를 작성하려고 했습니다.

AudioListener에서 무슨 일이 일어나고 있는지 잘못 이해했습니다... 약간의 디버깅 후에 bubleCleanup 변환에 일치하는 문제가 있는 것 같습니다. 자세한 내용은 https://github.com/mrdoob/three.js/pull/19934#issuecomment -667411997을 참조하세요. 나는 몇 가지 다른 클래스에서 이 문제에 부딪쳤기 때문에 훨씬 더 진행하기 전에 정렬해야 할 것입니다.

이것은 일부 파일의 경우이지만 전부는 아닙니다. 우리는 그러한 문제를 예상하고 있었습니다.

따라가는 분들은 여기 에서 토론 내용을 빠르게 읽으십시오.

그 동안 src/loaders !