Looking for a guide to write your own polyfills?

Looking for a guide to write your own polyfills?

(자신만의 polyfills 작성 가이드를 찾고 계십니까?)

출처 : https://addyosmani.com/blog/writing-polyfills/

The Developer's Guide To Writing Cross-Browser JavaScript Polyfills

(Cross-Browser JavaScript Polyfills 작성을위한 개발자 안내서)

모범 사례를지지하고 다른 사람들이 현대 웹에서 현대적인 기능을 사용하도록 도우려는 것이

디자이너와 개발자로서의 책임 중 하나라고 생각합니다.

동시에 이전 브라우저를 사용하는 사용자를 피해야하는 번거로움을 피하기 위해 최선을 다해야합니다.

Remy Sharp가 Polyfills라는 용어를 사용하여 이러한 기능이 없는 사용자를 위해 새로운 브라우저의 기본 기능에서

발견되는 표준 API를 복제하는 JavaScript shim을 설명하는것은 이를 달성하는 데 도움이됩니다.

오늘의 포스트에서, 나는 그 길을 따라 배운 교훈과 함께 크로스 브라우저 폴리필 (cross-browser polyfill)을 만드는 나의 경험에 대해 자세히 이야기 할 것입니다. 또한 자신 만의 폴리 필을 작성하고 개발자들이 처음 코딩 할 때 두려움을 피할 수있는 방법에 대한 몇 가지 팁을 제공 할 것입니다.

일부 브라우저에서는 기본적으로 지원되지 않기 때문에 기능이 제공하지 않는 기능을 사용하지 않기로 결정할 필요는 없습니다. Polyfill은 대상 브라우저에 관계없이 적절한 이유로 기능을 사용하도록 선택하는 자유가 귀하의 손에 달려 있음을 의미합니다.

Why do developers write polyfills? (개발자는 왜 polyfill을 작성해야할까요?)

polyfill을 작성하는 것은 브라우저의 기능 구현 간의 미묘한 차이점에 대해 더 배울 수있는 환상적인 기회이지만, 

우리가 이를 쓰는 진정한 이유는 그것이 이루어질 수 있는지를 알고자하는 욕구가 있기 때문입니다.

우리는 '여기에 실제로 사용할 수있는 놀라운 기능이 있지만 브라우저 간 호환성에 대해 걱정하지 않고도 현재 프로덕션 환경에서 사용할 수 있습니다.'라고 말할 수 있기를 바랍니다. 웹상의 포괄성은 우리에게 중요합니다.

... 중략 ...

Feature detection

Prefixes

브라우저 공급 업체가 아직 완성되지 않은 기능이나 표준을 구현하려고 할때 (ex.border-radius)

각 브라우저에 고유 한 접두어(Prefixes)를 사용하여 기능이나 표준을 풀어줍니다.

Chrome / Safari	webkit	(ex. -webkit-border-radius)
Firefox	moz	(ex. -moz-border-radius)
Opera	o	(ex. -o-border-radius)
Microsft	ms	(ex. -ms-border-radius)

접두어가 없는 경우도 고려해야합니다.

polyfill을 작성하려고 시도하는 것에 따라, 아래에 작성한 것과 같은 접두어 테스터를 찾을 수 있습니다.

/*
* vendorPrefix.js - Copyright(c) Addy Osmani 2011.
* http://github.com/addyosmani
* Tests for native support of a browser property in a specific context
* If supported, a value will be returned.
*/

function getPrefix(prop, context) {
    var vendorPrefixes = ['moz', 'webkit', 'khtml', 'o', 'ms'],
        upper = prop.charAt(0).toUpperCase() + prop.slice(1),
        pref, len = vendorPrefixes.length,
        q = null;

    while (len--) {
        q = vendorPrefixes[len];
        if (context.toString().indexOf('style')) {
            q = q.charAt(0).toUpperCase() + q.slice(1);
        }
        if ((q + upper) in context) {
            pref = (q);
        }
    }
    if (prop in context) {
        pref = prop;
    }

    if (pref) {
        return '-' + pref.toLowerCase() + '-';
    }
    return '';
}

//LocalStorage test
console.log(getPrefix('localStorage', window));
//Page Visibility API
console.log(getPrefix('hidden', document));
//CSS3 transforms
console.log(getPrefix('transform', document.createElement('div').style));
//CSS3 transitions
console.log(getPrefix('transition', document.createElement('div').style));
//File API test (very basic test, ideally check against 'File' too)
console.log(getPrefix('FileReader', window));

당신이 할 수있는 두 가지 다른 방법이 있습니다.
특정 기능에 대한 접두사 테스트에 접근합니다.

다른 브라우저 공급 업체에서도 초기 기능을 구현하는 경우 polyfill을 미래 보장하려면

위의 모든 접두사에 대해 테스트 할 수 있습니다.

그러나 장기간에 걸쳐 polyfill을 유지하려는 경우 polyfilling하는 기능 (현재 WebKit / Chrome 및 IE)을 지원하는 것으로 알려진 브라우저의 접두사를 테스트 할 수 있습니다. 불필요한 테스트를 피하기 위해 사실상 마이크로 최적화입니다.

벤더 프리픽스를 설정하는 것은 unfinalized 기능을 탐지하는 기능의 첫 단계 일뿐입니다. 

이 섹션에서는 완성된 기능과 unfinalized 기능을 모두 감지하는 기능에 대해 더 자세히 설명 할 예정입니다. 

기능이 지원되는지 여부를 감지하는 데 사용할 수있는 여러 가지 방법이 있지만 모든 기능이 모든 기능에 적용되는 것은 아닙니다.

여기에는 테스트가 필요합니다.

- 현재 창에서 해당 기능 속성이 존재하는 경우 (익스플로러 지원)
- 기능 속성이 현재 문서에 존재하는 경우
- 기능 또는 그 기능 속성을 현재 문서의 새 요소로 만들 수있는 경우
- 기능 속성 또는 속성이 특정 요소 내에 존재하는 경우 (예 : 'placeholder'속성).

이것은 포괄적인 목록은 아니지만 기능 테스트에 대해 자세히 알고 싶다면 Modernizr 및 has.js 기능 검색 테스트를 통해

이 테스트가 어떻게 수행되는지에 대한 흥미로운 예제를 권하고 싶습니다.

... 중략 ...

이 외에도 염두에 두어야 할 유일한 사항은 크로스 브라우저를 사용하여 기능 테스트가 절대적으로 필요하다는 것입니다. 위의 테스트 예제를 볼 때 사소한 것처럼 보일 수도 있지만 일부 기능의 경우 복잡성이 증가하고 원하는 마지막 기능은 깨진 기능 감지 프로세스입니다.

... 중략 ...

Polyfill testing

Unit Testing

마무리를 위해, 저는 단위 테스트의 중요성으로 시작하는 polyfill 테스트에 대해 간략하게 설명하겠습니다. 
단위 테스트는 스크립트나 애플리케이션에서 테스트할 수 있는 가장 작은 부분을 테스트하기 위한 접근 방식이며, 

분리된 방법이나 기능이 예상대로 작동하도록 보장합니다. 

polyfill(Jasmine, QUnit 또는 다른 테스트 프레임워크의 사용 여부와 상관 없이)에 대한 유닛 테스트는 위험을 줄이고, 

실행하기 쉬워야 하며, polyfill이 진화하거나 변화함에 따라 유지 관리하기 쉬워야 합니다.

그러나 개발자는 안정적으로 실행하기가 까다로울 수 있습니다.

예를 들어, 개발자는 'Chrome'에서 실행하면서 IE 대비책을 위한 테스트를 시도해야하는지 궁금해 할 수 있습니다.

이것에 대한 답변은 어렵습니다.

필요한 이벤트를 정확하게 IE에서 시뮬레이션할 수 없는 경우,

테스트를 엣지, 최신 브라우저 및 기존 브라우저의 테스트로 분할하고 각 테스트 세트가 브라우저에서만 실행되도록 하십시오.

모든 브라우저를 올바르게 액세스하고 테스트하는 것도 중요합니다.

Cross-brower Testing

우리는 모든 개발자가 동일한 신뢰할 수있는 방식으로 브라우저 간 코드를 테스트한다고 가정하지만 이는 사실이 아닙니다.

예를 들어 IETester 또는 IE의 문서 모드가 Windows에서 전용 버전의 IE를 사용할 때 얻을 수있는 것과 동일한 1 : 1 렌더링 및 스크립팅 경험을 제공한다고 생각하는 수많은 개발자를 만나게되었습니다. 이것은 불행히도 매우 부정확합니다. 과거의 IETester와 IE Document / Browser Mode에 대한 테스트를 수행하여 원래 브라우저와 비교할 때 완전히 다른 레이아웃으로 나타났습니다.

'폴리필 (polyfills)에 관심이 있다면 브라우저에 도입된 새로운 기능을 중심으로 글을 쓰는 것이 좋습니다.

많은 시간을 할애할 수 있는 많은 프로젝트가 있습니다.

커뮤니티는 접근성을 위한 경계를 무너뜨리는데 도움이 되는 새롭고 유용한 솔루션을 항상 찾고 있으며,

앞에서 말했듯이 훌륭한 학습 활동입니다.'

따라서 polyfill의 작동 여부를 테스트하기 위해 두 가지 중 하나를 사용하지 않는 것이 좋습니다.

가양성 (false positive)의 위험을 피하려면 좀 더 안정적인 것이 필요합니다.

그렇다면 이상적인 테스트 설정은 무엇입니까?

개인적으로 Mac 용 VirtualBox를 IE 6, 8, 9, 10 및 기타 모든 최신 브라우저 용 Windows 7 이미지와 함께 사용합니다.

IE9 및 10PP2는 현재 문제없이 독립적으로 실행할 수 있지만 6 및 8에서는 이러한 독립 실행형 IE 실행 파일을 사용합니다.

위의 목록에서 IE7을 생략했다는 것을 알 수 있습니다.

IE7 테스트를 위해서는 WindowsXP 이미지와 원래 IE7 설치 사본 (Google을 통해 비교적 쉽게 찾을 수 있음)이 필요합니다.

위의 모든 설정을 얻는 데 어려움이 있을지 모르지만 필요할 때마다 VirtualBox를 백그라운드에서 쉽게 실행할 수 있습니다.

Conclusions(결론)

폴리필 (polyfills)에 관심이 있다면 브라우저에 도입 된 새로운 기능을 중심으로 글을 쓰는 것이 좋습니다. 많은 시간을 할애 할 수있는 많은 프로젝트가 있습니다. 지역 사회는 접근성을위한 경계를 무너 뜨리는 데 도움이되는 새롭고 유용한 솔루션을 항상 찾고 있으며 앞에서 말했듯이 훌륭한 학습 활동입니다.

마지막으로 polycill 작성에 대한 자신의 경험을 돕기 위해 Paul Irish와

그의 많은 자원에 대해 Mathias Bynens와 Remy Sharp에게이 게시물에 대한 기술적인 검토를 해주신 것에 대해 감사드립니다.

*

추가적으로 자스민에 대해서는

http://webframeworks.kr/getstarted/jasmine/

이 곳에서 한국어로 내용을 확인할 수 있다!