호환성_자바스크립트 기술을 트리거하는 더욱 우아한 이벤트

다양한 문제

기본 인터페이스를 호환 가능하게 만드는 것은 클라이언트가 어떤 인터페이스를 지원하는지 확인하기 위해 if를 사용하는 것에 지나지 않습니다. 가장 유명한 예는 이벤트입니다.

코드 복사 코드는 다음과 같습니다.

var addEvent = function( e, what, 어떻게) {
if (e.addEventListener) e.addEventListener(what, 어떻게, false)
else if (e.attachEvent) e.attachEvent('on' 무엇, 어떻게 )
}

여기에서는 이벤트를 요소에 바인딩할 때 발생할 수 있는 두 가지 상황, 즉 표준 W3C DOM 인터페이스와 DHTML에서 제공되는 인터페이스를 고려합니다. 물론 이 예는 아직 조잡하지만 문제를 설명하기에는 충분합니다.

원래 방법은 호환성 레이어에서 현장 판단을 호출하고 해당 if 분기를 입력하는 것입니다. 분명히, 이 "현장 판단" 방법은 효율적이지 않습니다. 나중에 사람들은 이 방법을 채택했습니다.

코드 복사 코드는 다음과 같습니다.

if ( MSIE) {
addEvent = function(e, 무엇을, 어떻게) {
e.attachEvent('on' 무엇을, 어떻게)
}
} else {
addEvent = function(e , what , How) {
e.addEventListener(what, How);
}
}

한 번의 판단 후에 addEvent에 다른 코드를 바인딩하여 실행할 필요가 없습니다. 시간 분기 판단.

안타깝게도 이 문제는 사소한 문제가 아닙니다. 우선, "attachEvent 사용"과 "클라이언트가 MSIE입니다"를 함께 바인딩하는 것은 매우 오래된 아이디어입니다. 언젠가 마이크로소프트의 양심이 알게 된다면 어떨까요? 현재 이런 일이 일어나고 있습니다. IE9는 DOM 인터페이스를 명확하게 지원하며 심지어 DOM3도 이를 지원합니다. 결과적으로 이러한 "양심 발견" 움직임은 많은 프런트 엔드 라이브러리를 손상시킬 것이며 (IE8이 등장했을 때와 마찬가지로) 코드를 수정해야 할 것입니다. 게다가 이 접근 방식은 "알 수 없는 클라이언트"를 고려하지 않습니다. 제가 아는 한, Google이 Chrome을 출시한 후 이로 인해 많은 클래스 라이브러리에서 코드를 다시 작성하게 되었습니다.
특징 감지

어떻게 하나요? 기능 감지는 "신규 클라이언트"로 인한 문제를 최소화할 수 있습니다. 클래스 라이브러리가 초기화될 때 정의된 코드 세트를 통해 클라이언트의 기능을 감지하고, 이 감지 값 세트를 사용하여 클래스 라이브러리 코드를 바인딩합니다.

코드 복사 코드는 다음과 같습니다.

var presentsAddEventListener = !!(checkerElement.addEventListener);
if (supportsAddEventListener) {
addEvent = function(e, what,how) {
e.addEventListener(what,how)
}
} else if (supportsAttachEvent) {
addEvent = function(e, what,how) {
e.attachEvent('on' what,how);
}
}

기능 감지는 실제로는 분리됩니다." 특정 클라이언트 사용" 및 "특정 기능 지원" - if 분기가 "기능이 있는지 여부"(인터페이스가 일관성이 있는지 여부)를 직접 판단하도록 하여 클라이언트의 "양심 발견"으로 인한 "좋은 의도"를 제거합니다. 클라이언트 제조사 나쁜 짓을 해라." 실제로 이는 역사적인 추세와도 일치합니다. 표준 인터페이스가 점차 대중화되고 클라이언트가 점차 "표현의 일관성"을 갖게 되면 일관된 호환성 계층 인터페이스를 만드는 것이 어떨까요?
떨어지는

코드를 다시 살펴보겠습니다. 일반적으로 호환성을 위해 기능 감지를 사용하는 코드 조각은 다음과 같습니다.

코드 복사 코드는 다음과 같습니다.

if (new_interface_Detected) {
comp = function() {uses_new_interface};
} else if (old_interface_Detected) {
comp = function() {uses_old_interface}; } else {
새로운 오류 발생('적응할 수 없음!')
}


즉, 프로세스는 다음과 같습니다.

클라이언트가 새 인터페이스를 지원하는 경우 호환성 레이어를 새 인터페이스에 바인딩합니다.
그렇지 않으면 클라이언트가 이전 인터페이스/일관되지 않은 인터페이스를 지원하는 경우 바인딩합니다. 새 인터페이스에 대한 호환성 레이어
그렇지 않으면 가능하면 오류 피드백을 제공하십시오

즉, 클라이언트가 "고급"을 지원하는 경우 호환성 레이어 프로그램이 "드롭"되었습니다. 기능(새 인터페이스, 표준 인터페이스), 그냥 "잡기" - 호환성 레이어에 홈이 있을 것입니다. 그렇지 않으면 계속해서 떨어집니다. 아, 이전 인터페이스가 포착되면 아무도 포착하지 못하면 이전 인터페이스를 사용하십시오. 그리고 - 찰칵 - 그는 땅에 쓰러져 마지막 숨을 거두며 소리쳤습니다. "당신이 사용하고 있는 클라이언트는 너무 틈새 시장입니다. 나는 당신에게 아무것도 할 수 없습니다!

이게 어떻게 생겼나요?

사실 JavaScript 객체 시스템의 메커니즘을 이해한다면 비유할 수 있습니다. 이것은 프로토타입이 아닌가요! 프로토타입 시스템은 이 드롭을 활용합니다. 특정 멤버를 찾고, 이 객체에 정의되어 있으면 이를 반환하고, 그렇지 않으면 프로토타입 체인을 따라 위쪽으로 검색합니다(예, 이번에는 위쪽입니다). 프로토타입 체인이 실제로 끝에 도달하면 정의되지 않은 값이 반환됩니다.

그냥 해보세요! 여기서는 addEvent를 예로 사용합니다. 먼저 아무것도 포함하지 않은 빈 드라이버를 정의합니다.

var nullDriver = {}

그런 다음 객체를 생성하고 프로토타입 체인이 이를 가리킵니다. ECMA V5 시대에는 Object.create를 사용할 수 있습니다. 불행히도 여전히 오래된 클라이언트가 많기 때문에(그렇지 않으면 호환 가능) 우리는 우리 자신의 기능을 만듭니다:

코드 복사 코드는 다음과 같습니다.

var 파생 = Object.create ? Object.create: function() {
var T = function() {} ;
return function(obj) {
T.prototype = obj;
return new T
}
}()

라고 생각할 수도 있습니다. 이 사용법 이상하지만 문제 없이 작동하고 느리지도 않습니다. Object.create의 절반 정도 빠릅니다. 이 파생 항목을 사용하여 시작합니다.

코드 복사 코드는 다음과 같습니다.

var dhtmlDriver = 파생( nullDriver);
var dhtmlDriverBugfix = 파생(dhtmlDriver)

여기서 bugfix는 일부 "버그" 및 특수 상황에 대해 정의된 특수 드라이버입니다. 여기서는 무시해도 됩니다. 좋습니다. DHTML의 addEvent가 무엇인가요?

코드 복사 코드는 다음과 같습니다.

if (supportsAttachEvent) {
dhtmlDriver .addEvent = function(e, what, How) {
e.attachEvent('on' what, How)
}
}

그럼 어쩌죠? 프로토타입 체인의 맨 앞에 있는 것은 W3C 표준 드라이버여야 합니다. 적어 두세요!

코드 복사 코드는 다음과 같습니다.

var w3cDriver = 파생(dhtmlDriverBugfix); 🎜>var w3cDriverBugfix = 파생(w3cDriver);

if (supportsAddEventListener) {
w3cDriver.addEvent = function(e, what,how) {
e.addEventListener(what,how)
}
}

마지막으로 최종 통화 인터페이스를 만들기 위해 뭔가를 추가하겠습니다. (w3cDriverBugfix가 너무 못생겼으니까...)

vardriver = 파생(w3cDriverBugfix)

그럼 호출됩니다. 보세요, 이것은 폴백의 진정한 본질을 잃지 않으면서 무섭게 보이는 분기 판단을 간단하고 효과적으로 만듭니다. addEventListener를 지원하는 클라이언트에서 addEvent를 호출하는 것은 w3cDriver.addEvent를 호출하는 것과 동일하며, 이를 수행하는 클라이언트에서는 맨 아래로 떨어집니다. addEventListener를 지원하지 않습니다. 다음으로 dhtmlDriver.addEvent를 호출합니다. 또한, 버그 수정을 수행하는 것도 쉽습니다. 원래 레이어는 전혀 영향을 받지 않는 동안 전용 "버그 수정" 레이어를 연결할 수 있습니다.
잠깐만요. 이렇게 많은 레이어를 상속하면

속도가 많이 느려지나요? 물론, 그러한 깊은 프로토타입 체인은 확실히 느리겠지만, 나에게는 방법이 있습니다. 객체의 속성에 쓸 때 무슨 일이 일어나는지 기억하시나요?

코드 복사 코드는 다음과 같습니다.

var ego = function(x) {return x}
for (var 각각의 드라이버) {
if (! (각각의 nullDriver)) {
driver[each] = ego(driver[each])
}
}


그렇습니다. 원래 프로토타입 체인에 높았던 방식이 갑자기 바닥으로 떨어지게 됩니다! 이번에는 프로토타입 체인을 검색할 필요가 없으며 하단에서 직접 속성을 가져옵니다. 여기서 ego 기능을 사용하는 이유는 일부 브라우저가 여기에서 코드를 "최적화"하는 것을 방지하기 위한 것입니다.
요약

여기서는 호환성에 대해 이야기하지만 그 본질은 언어 기능에 있습니다. 프로토타입 상속을 사용하면 이 번거로운 작업을 매우 우아하게 완료할 수 있습니다. 그렇습니다. 프레임의 아름다움은 외부뿐만 아니라 내부에서도, 심지어 가장 짜증나는 프레임일지라도 똑같이 우아해야 합니다.

여기 기술은 데스에서 만나보실 수 있습니다.
출처:typeof.net