Three.js: three.js용 Google 클로저 컴파일러 "externs" 파일?

아니요, three.js에는 외부 종속성이 없으므로 지금까지 이와 같은 것이 필요하지 않았습니다.

나도 알아, 하지만 컴파일 가능한 환경에서 THREE.js를 통합하는 것이 자체 프로젝트에서도 유용합니다.

그러한 파일은 어떻게 생겼습니까? 공유한 링크에 이미 설명되어 있다면 죄송합니다. 페이지가 너무 많아서(텍스트가 너무 많음) 읽고/이해할 수 없습니다.

@mrdoob , 다음에서 몇 가지 예를 찾을 수 있습니다.

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fexterns

또는

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fcontrib%2Fexterns

다음 사항도 중요합니다.

http://code.google.com/closure/compiler/docs/js-for-compiler.html

댓글/헤더? 코드를 읽기 어렵게 만들 것 같은데...

예, 하지만 전체 코드가 아닌 이 extern 파일에만 해당된다고 생각합니다. 누구나 할 수 있지만 필수는 아닙니다.

http://www.dotnetwise.com/Code/Externs/index.html 로 시도했습니다. 그러나 Three.js에서는 완전히 작동하지 않습니다. 모든 정의가 추출되지는 않습니다.

블로그 항목은 다음과 같습니다.

http://blog.dotnetwise.com/2009/11/closure-compiler-externs-extractor.html

this.method = function(){} 패턴을 지원하는 것 같지만 프로토타입은 지원하지 않습니다...

@mrdoob , 클로저 컴파일러 고급 옵티마이저가 있는 자체 응용 프로그램에 THREE.js를 통합하기 위한 권장 사항은 무엇입니까? 현재 불가능하다는 것이 사실입니까?

내가 아는 한 고급 옵티마이저는 사용 중인 클래스만 포함합니다. 맞나요? 이론적으로 작동해야 합니다... 작동하지 않습니까?

three.js로 고급 최적화를 시도하지는 않았지만 코드를 깨는 데 사용한 다른 것들을 기억합니다. 일반적으로 "안전"하지 않았습니다. 기본 단순 최적화에서는 항상 작동하지만 고급에서는 때때로 작동하지 않습니다.

라이브러리로 컴파일하면 코드가 깨지지만 응용 프로그램(메소드가 호출되고 모든 것이 포함됨)으로서 작동해야 합니다. 그렇죠?

@mrdoob 이 컴파일된(최적화된) 코드와 함께 라이브러리를 사용하려면 라이브러리의 모든 클래스와 메서드를 선언하는 "externs" 파일이 필요합니다. 그것 없이는 작동하지 않습니다. 그러나 three.js와 함께 작동하는 다른 도구가 있습니까? 내 three.js 응용 프로그램을 난독화(추한)하려면 필요합니다. 한 후보는 https://github.com/mishoo/UglifyJS 입니다. 그러나 나는 그것을 시도하지 않았습니다.

Google 클로저 externs는 컴파일된 코드에서 사용할 전체 개체를 설명하는 파일입니다.
이 파일이 없으면 컴파일러는 함수 이름에서 a() 또는 b()와 같은 것을 만듭니다.

예를 들어 다음은 JQuery용입니다. http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.7.js

externs가 three.js를 위한 것이라면 좋을 것입니다.

나는 괜찮지만 스스로 해결할 수는 없습니다. 다른 사람이 이 문제를 해결해야 합니다.

@yurikor , node.js를 사용할 때 node-browserify와 uglify-js를 함께 사용할 수 있습니다. 그러면 아무것도 만들 필요가 없습니다.

@remo 조언 감사합니다. 시도해 볼게.

이 문제는 잠시 동안 비활성화되었지만 나중에 누군가가 이 문제를 해결하고자 하는 경우를 위해 몇 가지 추가 정보가 있습니다.

내 프로젝트의 경우 내 프로젝트를 컴파일할 수 있는 충분한 threejs 내보내기가 있는 간단한 파일 을 만들었습니다. 클로저 컴파일러가 모든 유형을 확인하고 내 코드에서 몇 가지 버그를 찾을 수 있도록 했기 때문에 매우 유용한 유형 주석이 함께 제공됩니다. 이 파일을 수동으로 만들었습니다. 나는 주로 버그 검사를 위해 클로저 컴파일러를 사용합니다. 실제 축소를 위해서는 덜 강력하지만 안전한 uglifyjs 를 사용 합니다.

또한 클로저 컴파일러가 내 공용 인터페이스 기호의 이름을 바꾸는 것을 방지하기 위해 몇 줄의 코드 를 추가해야 blah.xyz 를 통해 액세스한 모든 속성의 이름을 변경하지만 blah["xyz"] 를 통해 액세스한 속성은 건드리지 않습니다.

마지막으로 window['ColladaLoader2'] = ColladaLoader2 라인 은 클로저 컴파일러에게 이 클래스를 전역 범위로 내보내야 함을 알리는 데 필요했습니다.

그러나 프로덕션에 클로저를 사용하지 않고 버그 검사만 사용하고 있습니까? 그래요
extern 파일을 유지 관리하는 것이 그만한 가치가 있는지 확실하지 않습니다. 그냥 실행 종료
적극적인 최적화가 없으면 extern 파일이 필요하지 않습니다.
하지만 여전히 내가 믿는 대부분의 검증 또는 아마도 모든
확인. 아마도 당신은 명확히 할 수 있습니까?

내 전화에서 보냈습니다. 문법과 간결함을 유감스럽게 생각합니다.
2013년 2월 12일 오전 5시 19분에 "Robert Carnecky" [email protected]이 다음과 같이 썼습니다.

이 문제는 잠시 동안 비활성화되었지만 누군가가 원하는 경우
향후 이 문제를 해결하려면 다음과 같은 몇 가지 추가 정보가 있습니다.

내 프로젝트의 경우 내 프로젝트를 컴파일할 수 있는 충분한 threejs 내보내기가 포함된 간단한 파일( https://github.com/crobi/ColladaAnimationCompress/blob/master/threejs-exports.js) 을 만들었습니다. 그것은 온다
클로저를 활성화할 때 매우 유용한 유형 주석 포함
컴파일러를 사용하여 모든 유형을 확인하고 내 코드에서 몇 가지 버그를 찾습니다. 나는 가지고있다
이 파일을 수동으로 생성했습니다. 나는 주로 버그에 클로저 컴파일러를 사용합니다.
확인, 실제 축소를 위해 덜 강력하지만 안전한 것을 사용합니다.
uglifyjs https://github.com/mishoo/UglifyJS.

또한 클로저 컴파일러가 내 공용 인터페이스의 이름을 바꾸는 것을 방지하기 위해
기호를 사용하려면 몇 줄의 코드 를 추가해야 했습니다
클로저 컴파일러는 blah.xyz를 통해 액세스되는 모든 속성의 이름을 바꿉니다.
그러나 blah["xyz"]를 통해 액세스되는 속성은 건드리지 않습니다.

마지막으로 https://github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3383 창['ColladaLoader2']
= ColladaLoader2(문자열 사용에 다시 주의)가 필요했습니다.
이 클래스를 전역 범위로 내보내야 하는 클로저 컴파일러.

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/mrdoob/three.js/issues/341#issuecomment -13426131에서 확인하세요.

내가 아는 한 단순 모드 는 유효성 검사를 전혀 수행하지 않습니다. 지역 변수의 이름을 바꾸고 알 수 없는 기호를 만나면 전역 변수라고 가정하고 그대로 둡니다.

고급 모드 는 강력한 형식의 언어에서 컴파일러처럼 작동합니다(형식 정보를 사용할 수 있다고 가정): 알 수 없는 함수 또는 속성에 대해 경고하고 잘못된 수의 인수로 함수를 호출하거나 수가 예상되었습니다.

예를 들어 단순 모드는 다음 코드를 변환합니다.

function fn() {
    var foo = {}; // local variable, safe to rename this
    foo.bar();    // undefined property, will crash here
}
fn();

어떤 경고도 없이

function fn(){({}).bar()}fn();

({}).bar() 에서 분명히 충돌합니다. 고급 모드는 다음 코드를 출력합니다.

({}).a(); // fn() inlined, private member 'bar' renamed to 'a'

여전히 충돌하지만 컴파일러는 경고도 제공합니다.

Property bar never defined on foo at line 3 character 0.

• 발견된 버그 클로저는 함수 이름에 오타가 있거나 x, y 및 z 구성 요소에 대한 세 개의 개별 숫자 대신 하나의 THREE.Vector3 를 Matrix4.makeTranslation 전달한 버그 유형이었습니다
• 전체 테스트 범위가 있었다면(나는 그렇지 않음) 조만간 해당 버그를 발견했을 것입니다. 그러나 즉시 나타나지 않으면 디버그하기 어려운 경우가 있습니다.
• threejs가 각 새 릴리스와 함께 최신 내보내기 파일을 제공했다면(유지 관리에 엄청난 노력이 필요함) 클로저 컴파일러는 API 변경에서 발생하는 모든 문제를 포착할 것입니다( Matrix4.makeTranslation 의 경우와 마찬가지).
• 클로저 컴파일러를 설정하는 것은 자바 런타임이 필요하기 때문에 나에게 너무 많은 작업입니다. 내 라이브러리를 구축하는 데 필요한 다른 모든 도구는 노드/자바스크립트를 기반으로 합니다.

저는 현재 THREE.js 애플리케이션을 클로저 라이브러리와 통합하기 위해 클로저 라이브러리 externs.js 파일을 만들고 있습니다. 기본적으로 우리가 찾으려는 것은 다음과 같습니다.
모든 THREE.js 클래스와 해당 클래스가 구현하는 프로토타입 메서드의 목록이 어딘가에 있습니까? 목록은 다음과 같아야 합니다.

THREE.텍스처
THREE.Texture.constructor
THREE.Texture.clone
THREE.Texture.dispose
THREE.DataTexture.clone

(등등...)

Ps- Three.js는 훌륭하지만 적절한 jsDocs를 사용하면 이 목록을 쉽게 추출할 수 있습니다. :)

여기 에 three.js 내보내기의 부분 구현이

@crobi : 왜 거기에 문서 주석을 넣었습니까? 아무래도 시간이 많이 걸리고 그럴 필요가 없을 것 같긴 한데...

@taoeffect : 주석은 대부분 클로저 컴파일러 고급 모드에 대한 것입니다. 나는 강력한 형식의 코드를 좋아합니다.

@crobi , 오 댓글로 인해 강제 입력이 발생합니까? 멋지네요.

클로저 컴파일러를 사용하여 유형 오류를 확인하는 경우에만. typescript 와 유사합니다. 둘 다 주석이 달린 자바스크립트를 일반 자바스크립트로 전처리합니다. 따라서 컴파일 타임 검사 전용입니다.

여기에 있는 클로저의 고급 최적화 모드에 대한 대부분의 의견은 정확하지 않습니다.

주요 문제를 해결하기 위해 다음 도구를 사용하여 모든 라이브러리 http://www.dotnetwise.com/Code/Externs/에 대한 클로저 extern을 자동으로 생성할 수 있습니다

또한 단순히 외부 라이브러리로 사용하는 대신 three.js를 코드에 대한 입력으로 사용하기로 결정했다면 플래그를 추가해야 합니다.

--language_in=ECMASCRIPT5

이에 대한 블로그 게시물을 작성해야 합니다.
중요한 예 및 Google Closure를 통해 실행하는지 확인
최적화가 잘 된 컴파일러는 차이를 만듭니다.
-벤

2014년 1월 13일 월요일 오후 12시 31분, Rodrigo Formigone <
[email protected]>은 다음과 같이 썼습니다.

또한 코드 입력으로 three.js를 사용하기로 결정했다면
단순히 외부 라이브러리로 사용하려면 플래그를 추가해야 합니다.

--language_in=ECMASCRIPT5

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/mrdoob/three.js/issues/341#issuecomment -32191167에서 확인하세요.
.

친애하는,
벤 휴스턴
음성: 613-762-4113 스카이프: ben.exocortex 트위터: @exocortexcom
http://Clara.io - 전문가급 WebGL 기반 3D 콘텐츠 제작

그런 글을 쓸 수 있을 것 같아요. 그러나 명확히 하기 위해 (externs 파일의 유무에 관계없이) 클로저를 통해 Three.js를 실행하려는 이유는 반드시 성능 최적화만을 위한 것은 아닙니다. 클로저는 기본적으로 JavaScript(특히 매우 큰 코드 기반)에서 유지 관리 가능한 코드를 작성하는 데 도움이 됩니다. 목표는 개발자가 JavaScript를 "피하는" 것이 아니라(GWT 또는 기타 유사한 도구를 사용하여) JavaScript를 "길들인"(기본 JS 작성)을 돕는 것입니다. 단순히 Three.js를 Closure 프로젝트의 일부로 컴파일하려고 하면 Three.js가 일부 표준을 준수하지 않을 수 있기 때문에 컴파일러가 소리를 지르게 할 수 있습니다(JSDoc이 충분하지 않은가요?). --language_in 컴파일러 플래그를 사용하면 현재로서는 문제가 해결되지만 몇 가지 경고가 표시됩니다. 단순히 자신의 JS 코드를 컴파일하고 싶지만 Three.js를 외부 라이브러리로 참조하려는 경우(따라서 Three.js의 모든 코드베이스를 건드리지 않고 최적화하지 않은 채로 두는 경우) 위에서 언급한 externs 파일이 필요합니다. externs 파일이 없으면 Closure는 THREE.*가 어디에도 선언되지 않았다는 컴파일 오류를 발생시킵니다.

Closure 프로젝트에서 Three.js를 사용하는 방법과 이유를 설명하는 블로그 게시물을 작성할 수는 없지만 Google Closure 도구에 대한 최고의 소개 프레젠테이션은 다음과 같습니다. (Google I/O 2011에서) https://www.youtube.com/watch?v=M3uWx-fhjUc (긴 비디오라는 것을 알고 있지만 컴파일러의 목적이 무엇인지, 다른 컴파일 모드가 실제로 무엇을 하는지 분명히 합니다. 또한 설명합니다. extern 파일이 필요한 이유).

안녕하세요, three.js를 사용하여 애플리케이션을 개발하기를 기대하고 있으므로 ADVANCED_OPTIMIZATIONS 옵션 지원을 원합니다.

데드 코드 제거는 임베딩 애플리케이션이 Three.js 기능의 일부만 사용할 때 강력하게 작동합니다.

현재 three.js는 "three.min.js가 필요합니다!"로 제한되어 있기 때문에 모든 단일 기능을 개발해야 합니다. 이 고전적인 접근 방식은 이해하기 쉽지만 이 접근 방식으로 작성된 코드의 경우 JavaScript 최소화 프로그램이 코드를 줄일 수 있습니다. 변수 이름 축소(짧은 변수 이름에는 효과적이지 않음), 공백 제거(들여쓰기 공백, 탭 및 줄 바꿈에만 유효) 및 기타 저렴한 방법으로 크기를 조정할 수 있습니다.

"Closure 컴파일러 스타일" 코드에 ADVANCED_OPTIMIZATIONS 옵션을 사용하면 대부분 큰 라이브러리에 가중치를 주는 전체 "필요하지 않은 코드"를 제거할 수 있습니다. Closure 라이브러리 와 같은 커졌지 만 라이브러리 사용자와 개발자는 대부분의 코드가 컴파일 단계에서 제거된다는 것을 알고 있기 때문에 상관하지 않습니다.

three.js는 이미 객체 지향 스타일로 작성되었기 때문에 전체 코드를 "클로저 컴파일러 스타일" 코드로 업데이트하는 것이 (기술적으로) 어렵지 않다고 생각합니다. 내가 걱정하는 것들...

• 클로저 컴파일러 스타일에는 각 함수에 대한 주석이 필요합니다. 현재 그들 중 누구도 없습니다. 지금까지 개발된 모든 기능에 주석을 추가하는 데 얼마나 걸립니까?
• 클로저 컴파일러에는 엄격한 유형 정의가 필요합니다. null 및 undefined에 대해서도 적절하게 작업해야 합니다. "null-allowed" 매개변수, "undefined-allowed" 매개변수, ...
• ADVANCED_OPTIMIZATIONS에 의해 컴파일된 "전체 버전 라이브러리"를 준비하려면 적절한 extern 파일을 준비해야 합니다.

하이 스케둘 소르,

이것은 좋은 아이디어입니다. 방법에 대한 작은 스니펫을 공유할 수 있습니까?
이것은 three.js에 추가되어야 합니까?

관련하여,

람순다르 마다반

2014년 6월 24일 화요일 오후 4:23 Schedul Xor [email protected]
썼다:

안녕하세요, three.js를 사용하여 애플리케이션을 개발하기를 기대하고 있습니다.
그래서 ADVANCED_OPTIMIZATIONS 옵션 지원을 원합니다.

데드 코드 제거는 임베딩 애플리케이션이 만 사용할 때 강력하게 작동합니다.
Three.js 함수의 일부입니다.

현재 three.js는 모든 단일 기능을 개발해야 합니다.
의도된 사용은 "3.min.js가 필요합니다!"로 제한됩니다. 이 고전
접근 방식은 이해하기 쉽지만 이 접근 방식으로 작성된 코드의 경우
JavaScript 최소화 프로그램은 변수 이름을 축소해야만 코드 크기를 줄일 수 있습니다.
(짧은 변수 이름에는 유효하지 않음), 공백 제거(유효
들여 쓰기 공백, 탭 및 줄 바꿈) 및 기타 저렴한 트릭.

ADVANCED_OPTIMIZATIONS 옵션을 "클로저 컴파일러 스타일"에 사용
코드에서 대부분 가중치를 부여하는 "필요하지 않은 코드" 전체를 제거할 수 있습니다.
대형 도서관. 클로저 라이브러리와 같은 라이브러리
https://developers.google.com/closure/library/ 가 커졌지만
라이브러리 사용자와 개발자는 그것을 알고 있기 때문에 그것에 대해 신경 쓰지 않습니다.
대부분의 코드는 컴파일 단계에서 제거됩니다.

three.js는 이미 객체 지향 스타일로 작성되었으므로
(기술적으로) 전체 코드를 "클로저 컴파일러"로 업데이트하는 것은 어렵지 않습니다.
styled" 코드. 내가 걱정하는 것은...

• 클로저 컴파일러 스타일에는 각 함수에 대한 주석이 필요합니다.
  현재 그들 중 누구도 없습니다. 주석을 추가하는 데 얼마나 걸립니까?
  이제까지 개발된 모든 기능에?
• 클로저 컴파일러에는 엄격한 유형 정의가 필요합니다. null에 대해서도
  정의되지 않은 경우 제대로 작동해야 합니다. 에게는 힘든 일이 될 수 있습니다
  "null-allowed" 매개변수, "undefined-allowed"가 있는 함수
  매개변수, ...
• 기대하고 있다면 적절한 externs 파일을 준비해야 합니다.
  에 의해 컴파일된 "전체 버전 라이브러리" 준비
  ADVANCED_OPTIMIZATIONS.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/mrdoob/three.js/issues/341#issuecomment -46957189.

@schedul-xor 우리는 확실히 도움이 필요합니다... 코드 주석이 실제로 필요한가요 아니면 extern으로 충분합니까?

안녕하세요,

저는 이 커뮤니티를 처음 사용합니다. 이 커뮤니티에 기여하는 데 관심이 있습니다.
변경.

관련하여,

람순다르 마다반

2014년 6월 24일 화요일 오후 7시 23분에 Mr.doob [email protected]에 다음과 같이 썼습니다.

@schedul-xor https://github.com/schedul-xor 우리는 확실히 도움이 필요합니다
그것으로 ... 코드 주석이 실제로 필요한지 아니면 충분합니까?
외부인?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/mrdoob/three.js/issues/341#issuecomment -46973166.

고급 최적화에는 특정 코딩 스타일이 필요합니다. 그렇지 않으면 코드가 손상될 수 있습니다. 예를 들어 three.js는 uniforms["diffuse"] 및 uniforms.diffuse 혼합합니다. 이는 클로저 고급 최적화에서 허용되지 않습니다. #3222도 참조하십시오.

모든 곳에 엄격한 유형 주석을 추가하는 것은 엄청난 양의 작업이며 많은 주석 행을 추가합니다(제 프로젝트에서는 행 수가 2배 증가했습니다).

다른 웹 프레임워크/언어에 대한 extern 파일을 갖는 것이 좋습니다.

튜토리얼 에 따르면, externs는 이름을 바꾸고 싶지 않은 변수를 보호하는 데 사용됩니다. 이것은 공격적인 변수 이름 변경으로부터 클로저 컴파일러 스타일 프로젝트에서 사용하는 타사 라이브러리(비클로저 컴파일러 스타일)를 보호하려는 경우에 사용하는 것입니다.

externs 파일이 제공되는 유일한 경우에도 컴파일러가 여전히 데드 코드를 자르려고 하는지 확실하지 않습니다. 모든 기능에 주석을 작성하는 것보다 extern 파일만 작성하면 훨씬 더 쉬울 것입니다...

제 생각에는 각 함수에 어노테이션을 작성하는 것이 extern을 작성하는 것보다 낫습니다. 왜냐하면 타입 정의 파일과 소스 코드가 다르면 나중에 extern 파일을 동기화하기 어려워지기 때문입니다. 각 기능 수정에 externs 파일 업데이트가 필요한 경우 얼마나 성가시게 될지 상상할 수 있습니다. 선택(externs 또는 /** */ 함수에 대한 주석)에는 주석이 필요하며 대부분의 경우 더 쉬운 방법이 이깁니다.

three.js는 대규모 프로젝트이기 때문에 어디서 먼저 작업해야 하는지 궁금합니다. 쉽게 할 수 있는 것부터 시작하는 것이 좋습니다.

파일 헤더를 넣고 함수별 정의 ​​스타일을 바꾸는 것은 어떨까요?

THREE.Material = function(){
  :
};
THREE.Material.prototype = {
    constructor: THREE.Material,
    setValues: function ( values1, value2 ) {}
    getValues: function () { return this.a; }
    :
};

↓

goog.provide('THREE.Material'); ← Write goog.provide('package.classname') at the first line

← three empty lines before <strong i="10">@constructor</strong>

/**
 * <strong i="11">@constructor</strong> ← Add <strong i="12">@constructor</strong> annotation to constructor
 */
THREE.Material = function(){
  :
};

← two empty lines before function definition
/**
 * <strong i="13">@param</strong> {!Array.<!string>} values1 Values1 explanation ← values1 is an array of strings. values1 can't be null, and elements inside values1 can't be null.
 * <strong i="14">@param</strong> {!number} value2 Value2 explanation ← value2 is a number.
 */
THREE.Material.prototype.setValue = function(values1, value2){
  goog.asserts.assertArray(values1);
  goog.asserts.assertNumber(value2);
  :
};


/**
 * <strong i="15">@return</strong> {!number} ← This function returns a non-null number.
 */
THREE.Material.prototype.getValue = function(){
  return this.a;
};

모든 매개변수 유형을 엄격하게 제한하고 값 유형을 null이 아닌 값으로 반환하는 것이 더 쉬울 것입니다. 이렇게 하면 ADVANCED_OPTIMIZATIONS 컴파일 오류를 훨씬 더 쉽게 전달할 수 있습니다.

흠, 나는 여전히 코드에 수많은 주석이 있는 것에 만족하지 않습니다. 때때로 나는 모든 것을 TypeScript 와 같은 것으로 포팅하는 것이 더 좋지 않은지 궁금합니다.

Typescript는 클로저보다 강력한 형식의 자바스크립트에서 훨씬 더 좋게 느껴집니다. 이것은 적당한 크기의 콜라다 로더를 먼저 클로저 호환 자바스크립트로 재작성한 다음 타이프스크립트로 재작성한 후의 경험입니다. 두 접근 방식 모두 컴파일 시간에 버그를 찾는 데 도움이 되었습니다. Closure는 내 코드에 대해 꽤 좋은 최적화(인라이닝, 데드 코드 제거)를 수행했으며 nullable 형식을 지원합니다. 반면에 엄청난 양의 주석은 주의를 산만하게 했고 IDE 지원(코드 완성을 위한)은 typescript만큼 좋지 않았습니다. 또한 ECMAScript6과 유사한 class 키워드로 인해 typescript로 클래스를 작성하는 것이 훨씬 쉽습니다.

그러나 그것은 개인적인 의견일 뿐입니다. 더 중요한 것은 고급 컴파일 모드에서 클로저를 공식적으로 지원하기 전에 모든 속성 액세스가 일관 적인지 확인해야 한다는 사실을 다시 강조하고 싶습니다. externs 파일을 갖는 것은 도움이 되지 않습니다. 속성 액세스는 내보내지지 않는 내부 개체에 대해 일관성이 있어야 합니다. 왜냐하면 당신은 그것들을 적극적으로 이름을 바꾸거나/인라인/제거하기를 _원하기 때문입니다. 모든 클래스와 모든 변수에 주석을 추가하면 일관성 없는 속성 액세스를 포착할 수 있지만 전체 three.js 코드베이스에 대해 이 작업을 수행하는 데 몇 주가 걸립니다(내 프로젝트에 주석을 추가하는 데 걸린 시간을 추정하면).

마지막으로 three.js와 같은 큰 프로젝트를 다른 언어/프레임워크/코딩 스타일로 이식하는 것은 자세히 논의해야 합니다.

좋습니다. three.js가 엄청나게 많다는 데 동의합니다. 따라서 각 기능에 주석을 추가하는 데 몇 주가 걸릴 수 있습니다. 클로저보다 더 나은 AltJS가 존재할 수 있습니다. 이것은 (다른 것으로 이식하기를 기대한다면) 더 깊이 논의해야 합니다.

죄송합니다. 기다릴 수 없습니다. 현재 커밋을 포크하고 포팅을 시작하겠습니다.

안녕하세요,

이 주석 추가를 자동화할 수 있습니까? 그렇다면 추가할 수 있습니다.
build.py에 추가하고 클로저의 고급 최적화를 활성화하기 직전에 추가합니다.

관련하여,

람순다르 마다반

2014년 6월 25일 수요일 오전 6:05, Schedul Xor [email protected]
썼다:

좋아요, three.js가 거대하다는 데 동의합니다. 따라서 각각에 주석을 추가합니다.
기능은 몇 주가 소요될 수 있습니다. 보다 나은 AltJS가 존재할 수 있습니다.
폐쇄. 이것은 논의되어야 합니다(만약 당신이 그것을
다른 것) 더 깊이.

죄송합니다. 기다릴 수 없습니다. 현재 커밋을 포크하고 포팅을 시작하겠습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/mrdoob/three.js/issues/341#issuecomment -47047966.

@ramsundhar20 , 제 의견으로는

Three.js에는 현재 1354개의 함수가 정의된 163개의 자바스크립트 파일이 포함되어 있습니다. 예, 그것은 거대하지만 너무 먼 목표는 아닙니다.

// 이 주제가 적절하지 않으면 두렵습니다 ...

@schedul-xor 다시 말하지만, 저는 기능별로 주석을 달고 싶지 않습니다./

@mrdoob 네 ,

귀하의 정책을 존중하여 내 포크 에만 기능별 설명을 추가하고 싶습니다. 또한 풀 리퀘스트는 절대 하지 않습니다. 대신 원래 three.js 수정 사항을 클로저 스타일의 포크로 이식하겠습니다. 귀하의 호의적인 배려를 부탁드립니다.

그 좋은 소리 :)

감사합니다! 작업을 시작하겠습니다.

클로저 컴파일러와 함께 사용할 기본 three.js externs 파일이 최소한 있습니까? 이는 Three.js 소스 코드에 추가 Google 스타일 주석이 필요하지 않습니다. 이는 three.js를 사용하는 외부 app.js에서 링크를 충분히 컴파일 가능/난독화하기 위한 것입니다.

나는 또한 three.js를 위한 고품질의 완전한 externs 파일에 매우 관심이 있습니다. 다음은 하나이지만 완전하지 않습니다.

https://github.com/cljsjs/packages/blob/master/three/resources/cljsjs/three/common/three.ext.js

한 가지 방법은 이 방법으로 시작하여 사용하는 항목을 수동으로 추가하는 것입니다.

예, 내 투표를 계산합니다. 고급 모드 컴파일 가능, 100% 유형 threejs 또는 최소한 externs 파일에 이상적입니다.

유형 추론이 향상되고 필요한 혼란이 줄어듭니다. 범위와 별칭이 있으면 코드를 클로저 라이브러리만큼 장황하게 읽을 필요가 없습니다. 깨끗한 코드의 경우 입력된 인라인 문서를 작성하는 것으로 귀결됩니다. 그것들은 모든 이점을 능가할 만큼 충분히 나쁜가?

고급 모드 + JS 압축 + 유형 기반 최적화와 같은 매우 공격적인 설정은 데드 코드를 제거할 뿐만 아니라 최적화 컴파일러가 할 수 있는 모든 멋진 작업을 수행할 수 있습니다.

명명된 상수 / 열거형은 숫자로 대체됩니다. 또한 컴파일러는 constness를 추적하고 다른 상수로 계산을 수행하고 마지막으로 필요한 곳에 일반 숫자를 삽입할 수 있습니다. 종속 흐름 제어는 물론 데드 코드 제거의 대상이 됩니다. 결과 응용 프로그램에 활성 호출 사이트가 하나만 있는 함수와 압축된 형식이 정의에서 저장하는 것보다 작아지는 함수는 인라인됩니다. 네임스페이스가 제거됩니다. 보호되지 않는 모든 이름은 최소로 축소됩니다.

조회는 JavaScript에서 비교적 비용이 많이 듭니다. 이름 바꾸기, 지속적인 접기 및 인라인을 결합하면 많은 조회와 수많은 함수 호출이 제거됩니다. 게다가 적절한 헤더가 주어지면(클로저 라이브러리에 하나가 있음) 모든 표준화된 WebGL 상수를 렌더러에 적용할 수 있습니다.

그 결과 더 작고 더 빠르며 자체 문서화되고 자동으로 사용자 정의 가능한 라이브러리가 됩니다. 컴파일러는 또한 더 공격적인 설정에서 더 많은 버그를 포착합니다. 아마도 코드 검토가 쉬워질 것입니다. 마지막으로 중요한 것은 난독화 효과입니다. 클라이언트 코드를 사용자 정의 라이브러리와 함께 사용하면 externs 파일을 통해 보존된 기호를 표시하는 코드보다 지적 재산권 도난을 훨씬 더 잘 방지할 수 있습니다.

위에서 언급한 지점을 찾을 수 없습니다. 아직 타이핑된 버전으로 작업하는 사람이 있습니까?

@mrdoob 메인 라인에 대한 마음의 변화에 ​​대한 희망이 있습니까?

기꺼이 도와드리겠습니다.

@mrdoob 메인 라인에 대한 마음의 변화에 ​​대한 희망이 있습니까?

현재 저는 WebGLRenderer 리팩토링에 집중하고 있습니다 😇

에 상수를 변경할 수 const 보다는 var 좋은 지원이 모두 WebGL이 브라우저 https://kangax.github.io/compat-table/es6/ (const-> 기본) 및 JS 엔진은 const 대한 최적화를 시작하고 있습니다. 고정 필드 최적화를 사용하여 전역 상수의 속도를 높입니다.

그러나 흥미롭게도 var 대신에 작동하기 때문에 내가 말하는 경우의 극히 일부에만 적용할 수 있습니다. 심지어 상수에 관한 경우에도 마찬가지입니다. 또한 JIT 컴파일러는 정의상 급하기 때문에 오프라인 도구에서 수행하는 전체 프로그램 최적화와 자연스럽게 경쟁할 수 없습니다. 모든 JS 엔진은 코드의 구조를 존중해야 하며 예를 들어 콘솔을 열고 거기에 넣은 프로그램을 찾고 특정 기능을 대체할 수 있을 것으로 기대하므로 임의로 리팩토링할 수 없습니다.

클로저 컴파일러 지원으로 돌아가기: 나는 약간의 읽기와 실험을 했습니다. 내가 알아낸 것은 다음과 같다.

• 고급 모드를 실행하는 데 주석이 필요하지 않습니다.
• 주석을 점진적으로 추가하여 최적화 수준을 높일 수 있으며,
• 로더가 계속 작동하려면 약간의 주의가 필요하지만 상당히 쉽습니다.

기본적으로 세 가지 사용 사례가 있습니다.

1. 모델은 애플리케이션 및 라이브러리와 함께 압축할 수 있습니다.
2. 응용 프로그램과 라이브러리가 압축됩니다. 모델은 런타임에 로드됩니다.
3. 라이브러리는 기본 모드로 컴파일되어 있으며 고급 모드 앱에서 사용하려고 합니다.

세 번째 것은 모든 Three.js에 대한 externs 파일이 필요하며 IMO의 이점이 너무 적기 때문에 많은 작업이 필요합니다. 그래서 나는 처음 두 가지에 대해서만 논의할 것입니다. 어쨌든 이것이 선호되는 것입니다:

컴파일러가 볼 때

anObject['aProperty']

속성 이름을 건드리지 않습니다(문자열은 변경되지 않음).

anObject.aProperty

반면에 anObject 가 컴파일되는 응용 프로그램의 외부에 있다는 것을 알지 못하는 한 컴파일러는 속성 이름을 일관되게 변경할 수 있습니다. 컴파일러는 내장 또는 명시적으로 제공된 _externs_를 통해 이를 알고 있습니다.

여기에 조리법이 있습니다:

• 로더가 점 표기법을 사용하여 속성에 일관되게 액세스하도록 합니다.
• 입력을 입력하고 JSON에 대해서만 externs 파일을 작성합니다.
• 해당 externs 파일로 컴파일하는 것은 유스 케이스 2가 작동하도록 하는 데 필요한 전부입니다.
• 사용 사례 1의 경우 externs 파일을 사용하지 않고 대신 JSON의 객체 키에서 따옴표를 제거합니다.

{
    "camera": {
        "object": {
    // ...

단순히 될 것입니다

{
    camera: {
        object: {
    // ...

아주 간단하지 않습니까?

사용 사례 1은 JSON 형식이 외부 바이너리 데이터(원시 또는 webgl-loader 또는 o3dgc를 통해 압축)를 허용할 때 훨씬 더 매력적입니다. 물론 기술적으로 클로저 지원과 완전히 직교하는 또 다른 기능입니다.

externs 파일은 파일 형식을 문서화하는 오래된 Wiki 페이지를 대체할 수도 있습니다 :-).

나는 이 문제가 꽤 오랫동안 닫혀 있었다는 것을 알고 있습니다. 그러나 최근에 클로저 컴파일러 프로젝트 내에서 three.js를 사용하여 동일한 문제가 발생하여 이 페이지를 방문했습니다. .d.ts(typescript 선언 파일)를 클로저 컴파일러 파일로 변환하는 도구를 작성했습니다. 이 도구와 설명된 ConfirmedTyped/threejs 설명자 파일을 사용하면 완벽하게 작동합니다.
도구: https://github.com/eredo/tsd2cce 또는 npm install -g tsd2cce를 통해 설치

도움이 되었기를 바랍니다...

저 를 완전히 도운

@eredo @Corkle 또는 다른 사람이 tsd2cce 를 사용하는 방법을 보여줄 수 있습니까? 첫 번째 인수는 분명히 .d.ts 정의 파일이지만 두 번째 인수는 무엇입니까? 이 문제가 발생합니다. https://github.com/eredo/tsd2cce/issues/6

실제로 2월의 r73 d.ts를 사용하면 tsd2cce에서 잘 작동하지만 r73은 나에게 너무 오래되었다는 것을 알았습니다.

이제 이를 수행하는 적절한 방법은 tsickle을 사용하여 d.ts 파일에서 생성하는 것입니다.

모두 안녕,

후손과 모든 사람의 이익을 위해 Google Closure Compiler의 ADVANCED_OPTIMIZATIONS 및 기타 조정을 사용하여 라이브러리를 더 축소하려는 내 자신의 시도에 대해 여기에 보고하기로 결정했습니다.

고급 최적화가 켜진 Three.min.js를 허용하는 extern.js를 만들었습니다. 완벽함과는 거리가 멉니다.

이를 생성하기 위해 이 스레드의 이전 예제를 기반으로 extern.js로 시작했습니다. 이 방법으로 컴파일하면 해당 extern 파일에 포함되지 않은 맹글링된 속성으로 인해 라이브러리가 손상되었습니다. 클로저 컴파일러에서 --property_renaming_report 옵션을 사용하여 맹글링된 속성의 전체 목록을 얻었습니다. 이러한 모든 속성을 extern.js에 추가한 후 속성은 더 이상 맹글링되지 않았고 출력은 SIMPLE_OPTIMIZATIONS와 동일했습니다. 거기에서 나는 extern.js의 섹션을 선택적으로/수동으로 주석 처리하기 시작했고 라이브러리가 여전히 축소된 형태로 작동하는지 확인했습니다.

이 추측 및 확인을 자동화하고 가능한 한 많은 속성 이름을 안전하게 조작하는 완벽한 extern.js를 얻고 싶습니다. THREE.JS에 대한 단위 테스트를 사용하고 테스트 실패를 초래한 맹글링된 propname을 프로그래밍 방식으로 결정하는 아이디어가 있었지만 현재 명령줄에서 단위 테스트를 실행하는 것은 불가능한 것 같습니다(예: phantomjs 사용). (아마 WebGL 때문일 것입니다) ?

어느 쪽이든 이것은 더 작은 축소 라이브러리를 향한 "진행"이므로 전체 SPA 자바 스크립트 크기를 줄이는 데 도움이 됩니다.

externs.js

업데이트된 package.json 빌드 클로저 명령

또한 build-closure 명령에서 볼 수 있듯이 문자열 바꾸기 명령을 사용하여 라이브러리에서 모든 console.warn 및 console.error 메시지를 제거했습니다. 이를 통해 코드의 특정 섹션을 주석 처리하여 지금까지 축소된 라이브러리를 약 20% 축소했으며 개선의 여지가 있습니다.

@mrdoob 여기에서 내 방법과 같은

@medmr1 굉장합니다! three.js 라이브러리를 하나로 통합하여 앱을 컴파일해 보셨습니까? 이렇게 하면 externs 파일이 이상적으로 필요하지 않습니다.

나는 클로저 내에서 전체를 구축하려고 시도하지 않았습니다. 그것은 잘 작동할 수 있지만 프로그래밍 방식으로 참조되는 일부 속성을 맹글링하는 것과 관련하여 여전히 문제가 있을 것이라고 생각합니까? var thing = ShaderLib[ shaderType + "BumpMapFrag"] 와 같은 IE 항목 그러나 아마도 많은 문제를 해결할 수 있을까요?

예, var thing = ShaderLib[ shaderType + "BumpMapFrag"] 와 같은 항목은 고급 최적화로 인해 중단됩니다. 속성 참조는 정적으로 분석할 수 있어야 합니다. 다음과 같이 할 수 있습니다.

function(shaderType) {
  if (shaderType == "a") {
    return ShaderLib.aBumpMapFrag;
  }
  if (shaderType == "b") {
    return ShaderLib.bBumpMapFrag;
  }
...

대부분의 사람들이 Closure Compiler로 앱을 컴파일하지 않고 게시된 축소 버전만 사용하므로 올바른 externs 파일을 빌드하는 것은 프로젝트 전체에 확실히 더 유리합니다.

extern 대신
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export -export-sometype