jsdom 🚀 - MutationObserver에 대한 지원 추가

이것도 필요합니다. 누군가가 나를 올바른 방향으로 안내할 수 있다면 기꺼이 풀 리퀘스트를 수행할 것입니다.

SegFaultx64 에 2014년 12월 02일

@ SegFaultx64 이 문제에 대한 첫 번째 게시물에서 schettino72가 제공한 URL은 "올바른 방향"입니다.

lddubeau 에 2014년 12월 02일

👎5

공평하게, 나는 우리가 이 큰 프로젝트에 어떻게 관찰자를 등록할지 잘 모르겠습니다. 그런 물건을 보관하는 곳이 있습니까?

SegFaultx64 에 2014년 12월 02일

@ SegFaultx64 jsdom의 해당 부분을 보지 않았기 때문에 가장 좋은 방법이 무엇인지 명확하지 않습니다. NS 메소드를 수정하는 작업을 할 때(#727 참조; 명목상 버그 수정이지만 jsdom의 내장에 상당한 변경이 필요했습니다) 나는 유사한 구조를 찾고 새로운 클래스/데이터/ 등. 나는 내가 가장 좋다고 생각하는 대로 진행했고, Domenic은 몇 가지 의견을 말했고, 나는 조정이 필요한 부분을 조정했고 그게 전부였습니다.

lddubeau 에 2014년 12월 02일

@lddubeau 네, 포인터 주셔서 감사합니다. 실제로 MutationObserver https://github.com/megawac/MutationObserver.js/blob/master/MutationObserver.js에 대한 멋진 shim을 찾았습니다

SegFaultx64 에 2014년 12월 02일

내 유일한 조언은 https://dom.spec.whatwg.org/ 를 정독하고 돌연변이 레코드가 대기열에 있는 위치에 대한 세부 정보를 살펴보는 것입니다. 우리가 여전히 새로운 DOM 표준으로 전환하고 있기 때문에 jsdom에서 적절한 대응물을 찾는 것이 까다로울 수 있지만 적어도 사양은 구현해야 할 사항에 대한 지침을 제공할 것입니다.

domenic 에 2014년 12월 02일

이것에 대한 업데이트가 있습니까?

kresli 에 2015년 10월 27일

@kresli 풀 리퀘스트를 환영합니다!

domenic 에 2015년 10월 27일

어떻게 해야할지 모르겠으나 몇가지 실험을 해보기로 했습니다. 최악의 경우는 내가 조금 배우고, 최선의 경우는 내가 기여할 수 있을 것입니다.

저는 현재 jsdom이 어떻게 구성되어 있고 webidl이 어떻게 작동하는지(그리고 jsdom에서 사용되는지) 이해하려고 노력하고 있습니다.

~~MutationObserver: https://dxr.mozilla.org/mozilla-central/source/dom/webidl/MutationObserver.webidl~~~~~

이제 조금 더 잘 이해합니다. 사용할 인터페이스는 여기에 설명된 것이어야 합니다. https://dom.spec.whatwg.org/#interface -mutationobserver - 맞습니까?

henrikkorsgaard 에 2016년 01월 09일

@henrikkorsgaard 맞습니다! jsdom에서 작동하게 하려면 몇 가지 작업부터 시작해야 합니다.

적절한 MutationObserver.idl을 https://github.com/tmpvar/jsdom/tree/master/lib/jsdom/living/nodes에 추가
MutationObserver-impl.js 파일도 해당 폴더에 추가하십시오. 여기에서 실제 구현 작업이 진행됩니다. 예를 들어 사양에는 "각 MutationObserver 개체에는 이러한 관련 개념이 있습니다."라고 나와 있습니다. 그것들은 아마도 impl(= 구현) 클래스의 인스턴스 변수일 것입니다.

그런 다음 impl 클래스에서 관찰, 연결 해제 및 takeRecords 메서드와 생성자를 "그냥" 구현해야 합니다. 일반적으로 가능한 한 사양을 따르도록 노력해야 합니다. ( @Sebmaster , 생성자를 수행하는 방법을 설명할 수 있습니까?)

이 경우 CharacterData와 같은 단순한 것과 달리 많은 변경 사항이 다른 jsdom impl 파일을 수정해야 합니다. 예를 들어 사양에는 "각 노드에는 등록된 관찰자의 관련 목록이 있습니다."라고 나와 있습니다. 이를 위해서는 Node impl에 인스턴스 변수를 추가해야 합니다.

사양은 또한 "관련된 유사 출처 브라우징 컨텍스트의 각 단위에는 초기에 설정되지 않은 돌연변이 관찰자 복합 마이크로태스크 대기열 플래그와 초기에 비어 있는 관련 MutationObserver 개체 목록이 있습니다."라고 말합니다. jsdom에서 "관련 유사 출처 브라우징 컨텍스트의 단위"가 명확하지 않기 때문에 이것은 조금 더 까다롭습니다. 이를 위해 내가 할 일은 그것들을 Window 객체에 놓는 것부터 시작하는 것입니다. Window 객체는 아직 IDL을 사용하지 않으므로 Window.js에 밑줄 접두사가 붙은 속성을 추가하기만 하면 됩니다. 미래에 우리는 여러 창에서 사물이 추적되는지 확인하는 것에 대해 걱정할 수 있습니다(즉, iframe 관리). 그러나 현재로서는 창을 두기에 좋은 장소입니다.

마지막으로, "돌연변이 레코드를 큐에 넣는" 적절한 위치를 찾아서 구현의 많은 부분을 처리합니다. https://dom.spec.whatwg.org/#queue -a-mutation-record로 이동하여 "queue a mutation record"를 클릭하면 발생하는 사양의 모든 위치를 볼 수 있습니다. jsdom에는 상황이 발생할 때 사양이 수행하는 것과 똑같은 후크가 모두 없기 때문에 이것은 약간 까다로울 것입니다. 그러나 jsdom의 _attrModified, _descendantRemoved 및 _descendantAdded 후크를 사용하여 수행할 수 있어야 합니다. https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/attributes.js 에는 "TODO 돌연변이 관찰자 항목"도 있습니다.

도움이 되기를 바랍니다!

domenic 에 2016년 01월 10일

👍3

엄청난 :)

다시 말하지만, 저는 webidl 및 더 큰 코드베이스에 대한 경험이 많지 않습니다. 나는 또한 몇 가지 기한으로 인해 약간 무리가 있습니다 ;)

나는 최선을 다하고 앞으로 몇 주 동안 그것을 할 것입니다. 저도 한번 테스트 케이스를 만들어 보겠습니다.

henrikkorsgaard 에 2016년 01월 10일

확인,

나는 지금까지 idl과 Impl을 만들고 그것을 window.js에 요구했습니다.

이제 테스트 파일을 만들려고 하고 창 접두사를 사용하여 new MutationObserver()를 호출할 수 있습니다.

const window = jsdom("<html><body><div id='mutation'></div></body></html>").defaultView;

let observer = new window.MutationObserver(function(mutations){
      console.log(mutations);
});

여기에 속임수가 누락되었거나 MutationObserver를 전역 개체로 노출해야 하는 곳이 있습니까(창 개체에서 호출하지 않고 호출됨).

Window.js에 다음 줄을 추가했습니다.

const MutationObserver = require("../living/generated/MutationObserver");

이런 질문을 해서 죄송합니다. 테스트를 시작하고 jsdom 아키텍처/패턴을 따를 수 있도록 몇 가지 진입점을 설정하려고 합니다.

henrikkorsgaard 에 2016년 01월 10일

👍1

아 죄송합니다 그 부분을 깜빡했네요. https://github.com/tmpvar/jsdom/blob/28f00b30236d540df1777ca6c2c0ee9e5e19fe5b/lib/jsdom/living/index.js#L28 과 같은 줄을 추가해야 합니다.

domenic 에 2016년 01월 10일

돌연변이 작업 을 @domenic 의 아이디어가 작동할 것이라고 생각합니다( webkit은 전용 스레드/대기열에 돌연변이 레코드를 추가합니다 ). 그러나 이것은 또한 대기열의 어떤 형태와 더 중요하게는 대기열에 있는 것을 실행하는 일부 논리를 필요로 합니다. 이것은 두 가지 질문으로 이어집니다.

이러한 대기열의 이점을 얻을 수 있는 jsdom의 다른 구성 요소가 있습니까? 아키텍처 및 (미래) 통합 측면에서 여기에서 고려해야 할 사항이 있습니까?

타이머(jsdom에 전역 틱이 있습니까?) 또는 단지 약속/완료 콜백 구조를 기반으로 대기열에서 작업을 실행하는 것이 가장 현명할까요?

저는 매우 기본적인 구현을 완료하고 미래의 구현을 안내하기 위해 광범위한 테스트 사례를 작성하는 데 집중하고 있습니다.

henrikkorsgaard 에 2016년 01월 10일

따라서 마이크로태스크는 기본적으로 process.nextTick(fn) 입니다. 이것은 복합 마이크로 태스크 비즈니스와 "복합 마이크로 태스크 하위 태스크 실행"으로 인해 돌연변이 관찰자에게 조금 더 까다롭습니다. 나는 _ 생각 _ 대부분 그것을 무시할 수 있습니다. jsdom은 설정 중인 항목에 대해 걱정할 필요가 없습니다.

따라서 사양에 "돌연변이 관찰자에게 알리기 위해 복합 마이크로태스크 대기열에 추가"라고 표시되면 process.nextTick(notifyMutationObservers) 합니다. 그런 다음 notifyMutationObservers 내부에서 3단계는 하위 단계를 동기적으로 수행하는 돌연변이 관찰자에 대한 루프일 수 있다고 생각합니다.

domenic 에 2016년 01월 10일

테스트를 위해 https://github.com/tmpvar/jsdom/blob/master/Contributing.md 를 확인

domenic 에 2016년 01월 10일

이것은 질문하기에 적절한 장소가 아닐 수도 있지만 impl 파일(Node-impl -> MutationObserver-Impl) 간에 webidl 스키마 개체(예: /generated/MutationRecord.js)를 앞뒤로 전달하는 방법을 이해하는 데 문제가 있습니다. .

MutationRecords의 스키마를 미러링하는 순수 JSON 개체로 개체를 구성하고 돌연변이가 발생할 때 Node-impl에서 MutationObserver로 전달하고 싶은 유혹이 있습니다. 이것이 사양에 설명된 대로 MutationObservers의 모든 측면을 구현하려는 야심을 깨뜨릴 것이라고 생각합니다.

나는 이것이 jsdom webidl 아키텍처/객체 모델/인터페이스에 익숙하지 않기 때문이라고 생각합니다. 코드 내의 예는 또한 impl 파일에서 /generated/ 객체로 작업하는 것을 이해하는 데 도움이 될 것입니다.

henrikkorsgaard 에 2016년 01월 13일

우리는 아마도 이것을 어딘가에 문서화해야 하지만 여기에 간다:

일반적으로 생성된 API를 통과하는 모든 인수는 자동으로 언박싱/리박싱되므로 생성된 객체에 대해 신경 쓸 필요가 없습니다. 구현 객체만 중요합니다. 제외 - 실제로는 아닙니다. 우리가 이미 IDL 기반으로 _모든 것_을 전환했다면 이것은 사실이 될 것입니다. 그렇지 않습니다. 인수 및 반환 값은 작동하지만 비 IDL 클래스(예: Window)와 상호 작용할 때마다 인수를 직접 제공할 때 unboxing/reboxing을 수행해야 합니다(예 : https://github. com/tmpvar/jsdom/blob/master/lib/jsdom/living/events/EventTarget-impl.js#L103 , 여기서 Window는 아직 idl되지 않았지만 EventTarget(Windows가 상속하는 부터) 입니다. 필요한 경우 idlUtils.wrapperForImpl / idlUtils.implForWrapper 수동 복싱을 수행합니다.

따라서 일반적으로 Impl 객체를 생성하려고 합니다. 이렇게 하려면 생성된 파일이 필요하고 내보내기에 대해 createImpl 를 호출합니다. args의 배열(public-constructor 인수의 경우)과 private args의 객체(둘 모두 impl 클래스에 제공됨)를 취합니다. 이에 대한 예는 https://github.com/tmpvar/jsdom/blob/9dd9069354e36c077032f4cbcb1616a7d9e6f0c4/lib/jsdom/living/nodes/Document-impl.js#L549 를 참조

나는 이것이 전체를 파악하기에 충분히 깊이 있지 않다는 것을 알고 있습니다(제 생각에는). 따라서 더 구체적인 것이 있으면 기꺼이 더 설명하겠습니다.

Sebmaster 에 2016년 01월 13일

@Sebmaster 감사합니다, 많은 도움이 되었습니다.

예, API/객체를 통합하고 사용하는 방법에 대한 몇 가지 예와 함께 이것을 문서화하면 도움이 될 것이지만 다음 몇 단계에 대해서는 충분히 알고 있다고 생각합니다.

henrikkorsgaard 에 2016년 01월 15일

빠른 업데이트!
MutationRecord가 사양을 따를 경우 W3C 테스트 는 실패할 것입니다(제 생각에는). 나는 그들의 저장소에 의견을 남겼습니다.

내 목적을 위해 로컬로 업데이트하지만 W3C/jsdom에 커밋할지 확실하지 않습니다. 즉, 나에게도 그 일을 마칠 시간이 없다면 말이다.

그러나 속성 돌연변이는 이제 대부분의 테스트를 통과했으며 주말이나 다음 주 초에 pull 요청을 할 것입니다.

henrikkorsgaard 에 2016년 01월 15일

정말 흥미진진합니다! 문제가 무엇인지 조금 더 자세히 설명해 주시겠습니까? 나는 https://github.com/w3c/web-platform-tests/issues/2482 를 따라갈 수 없었습니다. 그래서 아마도: MutationRecord의 속성 값이 테스트에서 예상하는 것과 사양에 필요한 것이 무엇이라고 생각합니까? ?

domenic 에 2016년 01월 15일

문제는 테스트가 비교할 전체 mutationRecord를 지정하지 않는다는 것입니다. 따라서 첫 번째 테스트 사례 에서 테스트는 id 값을 변경하고 결과적으로 반환된 돌연변이 레코드는 이전 값 속성을 갖게 됩니다. oldValue 속성이 예상 개체에 정의되어 있지 않아 테스트가 실패합니다. 내가 이해하는 것처럼 돌연변이 레코드는 null인 경우에도 항상 모든 속성을 포함해야 합니다. 이 경우 DOMString null이어야 합니다. 테스트 케이스에 속성이 설정되지 않은 경우 테스트는 null(typeof 개체)과 null(typeof 문자열)을 비교하고 실패하게 됩니다.

테스트는 느리게 구성됩니다. 예를 들어 정의되지 않은 필드는 자동으로 null(객체)로 설정됩니다. 이것은 a) mutationRecord가 예상 레코드 객체(예: oldValue)에 설정되지 않은 속성을 반환하고 b) mutation 레코드 속성이 DOMstring null(예: attributeNamespace)일 때 테스트가 실패하도록 합니다.

맞는 말이다?

내가 옳다면 고칠 수 있지만 모든 경우를 하나씩 처리해야 합니다. 이것은 jsdom 및 w3c 테스트 모두에 대한 외부인으로서 약간 어려울 수 있습니다. :)

henrikkorsgaard 에 2016년 01월 15일

죄송합니다. 단순화할 수 있습니까? 나는 다음 형식의 답변을 선호합니다. 테스트에서는 oldValue가 null이거나 정의되지 않은 것으로 예상하지만 사양은 "null" 값을 제공합니다. 또는 유사합니다.

domenic 에 2016년 01월 15일

위에서 참조한 테스트는 암시적으로 oldValue가 null일 것으로 예상합니다. "n"이어야 합니다.

해당 파일의 모든 테스트 사례는 attributeNamespace가 null(객체)일 것으로 예상하며 사양에 따라 DOMString null이어야 합니다.

henrikkorsgaard 에 2016년 01월 15일

attributeNamespace의 유형은 DOMString?이므로 null이 허용됩니다("null"이 아니라 null만).

oldValue 사례에 대해 설명해주셔서 감사합니다. :).

domenic 에 2016년 01월 15일

네, 명확히 해 주셔서 감사합니다. 사양의 중요한 측면을 놓친 것 같습니다.

henrikkorsgaard 에 2016년 01월 15일

내 포크에 MutationObserver 분기를 추가하고 푸시했습니다. 현재 Attribute 및 CharacterData 돌연변이는 가장 중요한 w3c 테스트를 통과하고 있습니다.

알려진 이유/문제(범위 지원 #317 누락 등)로 인해 통과하지 못한 테스트는 어디에 문서화합니까?

henrikkorsgaard 에 2016년 01월 17일

우리가 하는 일은 웹 플랫폼 테스트를 위해 index.js 파일에 추가하는 것이지만 이유에 대한 설명과 함께 주석 처리되었습니다. 예를 들어 우리가 템플릿에 대해 수행하는 작업을 참조하십시오.

domenic 에 2016년 01월 18일

이게 완결까지 멀었나요?

MeirionHughes 에 2016년 06월 16일

돌연변이 이벤트가 8.5에서 제거된 것 같습니다 . 8.5로 돌아가서 폴리필에 의존하지 않고 사용자 정의 요소(돌연변이 관찰자 필요)를 테스트할 수 있는 방법이 있습니까? DOMParser 는 8.5에서 구현되지 않았으며 Shadow DOM 폴리필을 위해 이를 요구하므로 현재 JSDOM에서 테스트를 실행할 수 있어 차단됩니다. 여기에 어떤 지침이 도움이 될 것입니다. 불행히도 지금 당장은 이를 구현하기 위해 노력하고 도움을 줄 능력이 없습니다.

treshugart 에 2016년 10월 27일

나는 그렇게하는 방법을 알지 못합니다. 죄송합니다 :(.

domenic 에 2016년 10월 27일

이 문제를 옮기는 것을 도와드릴까요? https://github.com/henrikkorsgaard/jsdom/commits/MutationObserver 에서 일부 작업이 시작된 것 같습니다.

그러나 이것을 옮기기 위해 여전히 무엇이 필요한지 잘 모르겠습니다. MutationObserver 가 기본적으로 모든 곳에서 지원된다는 점을 감안할 때 이것이 존재하지 않는 것은 큰 격차처럼 느껴집니다. http://caniuse.com/#feat =mutationobserver

webcomponentsjs 폴리필을 활용할 수 있습니까? https://github.com/webcomponents/webcomponentsjs

alexreardon 에 2016년 11월 08일

풀 리퀘스트는 언제나 환영입니다. @henrikkorsgaard 의 작업은 확실히 시작하기에 좋은 장소입니다. 하지만 폴리필이 의미가 없다고 생각합니다.

domenic 에 2016년 11월 08일

내가 말할 수 있는 바에 따르면 돌연변이 이벤트는 성능 고려 사항 때문에 제거되었습니다. Mutation Observer가 브라우저에 의해 지정되고 구현된 것과 같은 이유입니다. 그러나 브라우저는 최소한 MO 지원이 구현될 때까지 해당 기능을 유지했습니다. 여기에서 실용적인 접근 방식은 이에 대한 지원을 다시 추가하는 것일 수 있으므로 최소한 MO는 이것이 구현될 때까지 폴리필될 수 있습니다. JSDOM의 유지 관리에 이상적이지 않으며 그 이후로 코드베이스가 분기되었을 수 있음을 알고 있습니다. 즉, 고려해 볼 가치가 있다고 생각합니다. 이것은 특히 웹 구성 요소가 프로덕션 앱을 위한 실행 가능한 솔루션이고 MO를 폴리필해야 하는 이 단계에서 큰 격차를 남깁니다. JSDOM에서 테스트를 실행할 수 있다면 좋을 것입니다.

treshugart 에 2016년 11월 09일

❤1

도움이된다면; 나는 폴리로 채워진 MO on-top jsdom; 여기 그리고 여기 . 나는 그것이 좋은 해결책이라고 말하지는 않겠지만 타이머 없이도

MeirionHughes 에 2016년 11월 09일

🎉8 👍6

4년 전인데 아직도 진행중인가요? 이 문제는 버전 9.0.0 이후 변경 로그에 언급되어 있습니다. 여러분, 이것에 대한 소식이 있습니까?

mtrabelsi 에 2017년 09월 11일

👍2 😕1 😄1

@MeirionHughes 파일이 원활하게 작동했습니다. 감사합니다!

mtrabelsi 에 2017년 09월 11일

이 문제에 대한 업데이트가 있습니까?

zelliott 에 2017년 10월 25일

https://twitter.com/slicknet/status/782274190451671040

domenic 에 2017년 10월 26일

😄7 ❤2

@domenic 의 링크에 대한 확장입니다.
@MeirionHughes가 제안한 해당 파일을 넣으려고 하면 지금까지 잘 작동했습니다.

mtrabelsi 에 2017년 10월 26일

@mtrabelsi @MeirionHughes 안녕하세요, Jest에서 작동하도록 관리하지 못했습니다. 이 오류가 발생했습니다. https://stackoverflow.com/questions/43190171/jsdom-cannot-read-property-location-of-null
JSDOM에서 MO를 어떻게 사용할 수 있었는지 설명해 주시겠습니까?

편집하다:
좋아, 나는 그것을 작동하게 만드는 것 같다 https://gist.github.com/romuleald/1b9272fce11d344e257d0bdfd3a984b0

romuleald 에 2017년 12월 29일

@romuleald 요점에 오류가 있습니다. this.expando 및 this.counter 를 설정한 다음 정적으로 액세스합니다. 이것은 _findMutations 에서 심각한 문제를 일으킬 것입니다. 변환하려는 typescript 파일에서 두 속성이 모두 정적임을 알 수 있습니다(ES6에서는 불가능). Util 클래스 아래에 다음 줄을 추가하는 것이 좋습니다.

Util.counter = 1;
Util.expando = 'mo_id';

그런 다음 생성자를 완전히 제거할 수 있습니다(클래스는 어쨌든 인스턴스화되지 않음).

지난 하루 반 동안 이 문제로 인해 발생한 문제를 디버깅했기 때문에 이것을 발견하는 데 창피할 정도로 오랜 시간이 걸렸습니다.

또한 shim의 기반이 된 소스는 CharacterData 노드의 .data 속성 변경을 지원하지 않습니다. 간단한 수정을 위해 이 댓글 위에 내 연결된 문제를 볼 수 있습니다.

mkohlmyr 에 2018년 02월 06일

당분간 https://github.com/megawac/MutationObserver.js 폴리필을 사용하여 이것을 테스트할 수 있었습니다.

저는 AVA를 사용합니다. 그리고 '''는 MutationObserver를 포함하는 내 모듈입니다.

import test from 'ava';
import delay from 'delay';
import jsdom from 'jsdom';
import m from '.';

const dom = new jsdom.JSDOM();
global.window = dom.window;
global.document = dom.window.document;

require('mutationobserver-shim');

global.MutationObserver = window.MutationObserver;

test('MutationObserver test', async t => {
    delay(500).then(() => {
        const el = document.createElement('div');
        el.id = 'late';
        document.body.appendChild(el);
    });

    const checkEl = await m('#late');
    t.is(checkEl.id, 'late');
});

Polyfill이기 때문에 표준 인터페이스와 다른 점이 있습니다. 하지만 이 문제는 진전이 없는 것 같으니 하나의 옵션으로 참고해 주시기 바랍니다.

1natsu172 에 2018년 03월 06일

🎉5

jsdom 및 jest를 사용하여 폴리필로 사용하는 또 다른 방법은 shim을 스크립트로 수동으로 로드하는 것입니다.

npm install mutationobserver-shim

예를 들어 beforeAll 함수 내부:

const mo = fs.readFileSync(
  path.resolve('node_modules', 'mutationobserver-shim', 'dist', 'mutationobserver.min.js'),
  { encoding: 'utf-8' },
);
const moScript = win.document.createElement('script');
moScript.textContent = mo;

win.document.body.appendChild(moScript);

이 "해킹"은 나를 위해, 아마도 다른 사람들에게도 효과가 있습니다 ;)

Zerogiven 에 2018년 03월 07일

🎉4

IIRC Jest용 setupFiles의 일부로 shim(pal-nodejs에서 조정된 버전의 코드를 사용했지만 위의 npm 패키지가 무엇을 기반으로 하는지 확실하지 않음)을 로드하는 것이 잘 작동한다는 것을 알았습니다. 관심 있는 사람이 있으면 다른 랩톱에서 더 구체적인 정보를 제공할 수 있습니다.

mkohlmyr 에 2018년 03월 08일

오픈한지 거의 5년 정도 되었는데 상태 업데이트가 있나요?

mendrik 에 2018년 05월 11일

https://twitter.com/slicknet/status/782274190451671040

domenic 에 2018년 05월 11일

😄11 👍3

@mendrik 조롱은 나를 위해 일했습니다 https://github.com/benitogf/corsarial/blob/master/test/specs/utils.js#L29 위에서 언급했듯이 폴리필 솔루션도 있습니다. 좋은 하루 되세요 :)

benitogf 에 2018년 05월 13일

https://github.com/skatejs/skatejs/blob/master/packages/ssr/register/MutationObserver.js에 부분 구현이 있습니다

treshugart 에 2018년 05월 14일

@benitogf 나는 그것을 시도했지만 어떻게 든 레코드가 나를 위해 발사되지 않았습니다 :(오류를 던지지 않았습니다.
@treshugart 어떻게 사용합니까? :)

mendrik 에 2018년 05월 14일

테스트에서 @mendrik , https://github.com/aurelia/pal-nodejs/blob/master/src/polyfills/mutation-observer.ts 가져오기
전역 변수로 설정합니다. 그거야!

mtrabelsi 에 2018년 05월 14일

@mendrik JSDOM https://github.com/skatejs/skatejs/tree/master/packages/ssr#usage 를 옵트아웃하려는 경우

treshugart 에 2018년 05월 16일

이것은 react-quill을 확장한 구성 요소를 테스트하려고 할 때 이 문제를 해결하기에 충분했습니다.

import 'mutationobserver-shim';

document.getSelection = () => null;

aharris 에 2019년 08월 21일

👍6

Jsdom: MutationObserver에 대한 지원 추가

가장 유용한 댓글

모든 53 댓글

관련 문제