문서 및 요소의 프로토 타입을 다루지 않는 일반적인 이유가 있습니까?문서 및 요소의 프로토 타입을 다루지 않는 일반적인 이유
저는 현재 프로젝트에 기존 프레임 워크의 많은 기능이 필요 없기 때문에 자신 만의 작은 프레임 워크를 만들고 싶습니다.
Element/Document-constructor을 지원하지 않는 브라우저를 지원할 필요가 없으며, 제어 할 수없는 스크립트도 실행하지 않습니다.
그래서 프로토 타입을 연장 하시겠습니까? 아니면 일반적인 방법으로 가서 요소/문서에서 자체 개체를 만들어야합니까?
기본 DOM 요소를 확장 하시겠습니까? 그렇다면,하지 마십시오. Juriy Zaytsev (일명 Kangax)는 명확하게 왜 What’s wrong with extending the DOM에 없는지 설명합니다.
바로 그 것이 내가 계획 한 것입니다. –
아주 특별한 경우에 대해 생각해 볼 수 있습니다. 예를 들어 개념 증명 시나리오의 일부를 디버깅하는 것, 지금까지 생산에 들어 가지 않는 것. 그래서이 대답은 유용하지 않습니다. – kisp
예, 불행히도. DOM 프로토 타입을 손으로 만져서 기능을 추가 할 수 있으면 좋겠지 만 실제로는 오늘날의 기술로는 신뢰할 수 없습니다.
Document, 및 기타는 브라우저에서 구현 한 '호스트 개체'일 수 있으며 프로토 타입을 만들 수 없습니다. 호스트 객체에는 네이티브 JavaScript 객체와 달리 다른 많은 이상한 동작이있을 수 있습니다. DOM 노드는 IE6-7 및 많은 오래된 틈새 및 모바일 브라우저의 호스트 객체입니다.
네이티브 JavaScript 객체로 구현 되더라도 .prototype에서 낚시를하러 갈 수있는 생성자 함수를 찾을 수있는 표준은 아직 없습니다. Document, 등은 단지 W3 DOM 인터페이스 이름이므로 구현 객체가 무엇인지 찾아 내지 못합니다.
최신 브라우저 (IE8 기본 모드 및 최신 버전의 Firefox, Opera 및 WebKit)는 생성자 함수를 사용할 수 있도록하므로 Document 또는 HTMLElement에 메서드를 추가 할 수 있습니다. 그렇지만 모든 브라우저가 동일한 이름으로 구현 된 DOM 인터페이스를 제공하지는 않기 때문에 객체가 노출되는 것과는 차이가 있습니다. (NodeList의 하위 인터페이스/구현은 특히 까다 롭습니다.)
DOM 프로토 타입이 실제로 Prototype.js 프레임 워크를보고 어떻게 작동하는지 확인할 수 있습니다. 작동하면 매우 부드럽습니다. 그러나 어디에서나 프로토 타입을 만들 수 없으므로 프레임 워크가 노드의 모든 인스턴스에 메서드를 복사하여 프로토 타입을 작성하지 못하는 일부 극히 추악한 작업을 수행하게됩니다. 그리고 나서 코드가이 기능을 강제해야 할 필요가 있다는 것을 잊어 버릴 수도 있습니다. 그래서 다른 함수가 이전에 같은 노드를 보완했는지 여부에 따라 작동하거나 작동하지 않을 수 있습니다. 이로 인해 브라우저 별, 상호 작용 순서 별, 경쟁 조건이 자주 발생하는 디버깅 문제가 발생합니다.
프로토 타입 작업을 제대로 지원되는 몇 가지 인터페이스로 제한하고 최신 브라우저를 제외한 모든 인터페이스를 포기할 수 있다면 그만 둘 수 있습니다.
DOM 노드는 브라우저가 생성자와 프로토 타입 체인을 제공하는 경우에도 여전히 호스트 객체입니다. –
여기에 무엇을 묻고 있는지 명확하지 않습니다. – Robusto
Element.prototype과 Document.prototype (HTMLDocument.prototype)에 대해 이야기합니다. 그 이유가 있다면 사용하지 않는 이유는 무엇입니까? –