Jak debugować dynamicznie ładowany JavaScript (z jQuery) w samym debugerze przeglądarki?

92

Dynamicznie dodawany skrypt nie pojawia się w sekcji skryptów debugera przeglądarki.

Wyjaśnienie:

Muszę użyć i użyłem

if( someCondition == true ){
   $.getScript("myScirpt.js", function() {
       alert('Load Complete');
       myFunction();
   });
}

aby myScript.js można było ładować dynamicznie po spełnieniu jakiegoś warunku ... A myFunction można wywołać dopiero po załadowaniu całego skryptu ...

Jednak przeglądarki nie wyświetlają dynamicznie ładowanego pliku myScript.js w sekcji skryptów debugera.

Czy jest inny sposób, aby wszystkie cele zostały osiągnięte, co sprawi, że będzie można debugować dynamicznie ładowany skrypt w samej przeglądarce?

— TwiToiT
źródło

Możliwy duplikat Czy możliwe jest debugowanie dynamicznego ładowania JavaScript przez jakiś debugger, taki jak WebKit, FireBug lub IE8 Developer Tool?

— GorvGoyl

2

użyj debugger;do automatycznego zatrzymania w dynamicznie załadowanym skrypcie, patrz javascript.info/debugging-chrome

— yu yang Jian

208

Możesz nadać dynamicznie ładowanemu skryptowi nazwę, tak aby był wyświetlany w debugerze JavaScript przeglądarki Chrome / Firefox. Aby to zrobić, umieść komentarz na końcu skryptu:

//# sourceURL=filename.js

Ten plik zostanie wyświetlony na karcie „Źródła” jako filename.js. Z mojego doświadczenia wynika, że w nazwie można użyć znaku \ 's, ale przy używaniu \ \ \ \' zachowuję się dziwnie.

Aby uzyskać więcej informacji, zobacz: Punkty przerwania w dynamicznym wycofywaniu kodu JavaScript // @ sourceurl

— znak
źródło

19

Zauważ, że został zmieniony na // #, chociaż // @ nadal działa w Chrome. W ten sam sposób można nazywać skrypty w plikach .html. Bądź ostrożny! Nie zostawiaj spacji przed i po znaku „=”.

— Mert Mertce

11

U mnie plik js był wyświetlany na liście źródeł w grupie o nazwie „(brak domeny)”. Warto o tym wspomnieć, ponieważ na początku to przegapiłem!

— JMac

7

Tylko wskazówka. Debuger Chrome wrzuca te pliki pseudo-javascript do elementu węzła „(no domain)” na karcie Źródła, przynajmniej podczas debugowania na hoście lokalnym. Tam je znalazłem.

— Robert Oschler,

1

Kolejną rzeczą, na którą należy uważać, jest styl komentarzy. Ten link „wycofanie adresu / / @ sourceURL”, który podałeś, wymienia zarówno „// # sourceURL =”, jak i „/ * # sourceURL =”. Dzieje się tak, ponieważ może to być również używane w CSS, gdzie musisz używać komentarzy blokowych, ponieważ komentarze jednowierszowe „//” są nieprawidłowe. Zaskoczyło mnie to, że nie możesz użyć „/ * sourceURL =” w javascript. Po prostu zostaje zignorowany.

— Jools

2

Ahaik, większość minifikatorów JavaScript usuwa te linie z etapów produkcji, przez co są bezużyteczne do diagnozowania błędów produkcyjnych.

— Lluís Suñol

16

Możesz użyć //# sourceURL=i //# sourceMappingURL=na końcu pliku skryptu lub tagu skryptu.

UWAGA: //@ sourceURL i //@ sourceMappingURLsą przestarzałe.

— xRavisher
źródło

Więcej informacji o wycofaniu: developers.google.com/web/updates/2013/06/…

— Pysis

Jasne, ale większość minifier usunie te linie na etapach produkcji.

— Lluís Suñol

13

Próbowałem użyć „// # sourceURL = nazwa_pliku.js”, który został zasugerowany jako obejście przez OP, ale nadal nie był wyświetlany w panelu Źródła, chyba że istniał już na moich kartach od poprzedniego czasu, kiedy spowodowało to wyjątek.

Kodowanie „debuggera”; linia zmusiła go do zerwania w tym miejscu. Następnie, gdy znalazłem się w moich zakładkach w panelu Źródła, mogłem ustawić punkty przerwania jak zwykle i usunąć "debugger"; linia.

— kevinpo
źródło

6

Może również pojawić się na liście (brak domeny) na karcie Źródła.

— Splaktar

1

Musiałem również użyć debugger;, a DevTools musiało być otwarte podczas ładowania skryptu.

— Barmar,

2

trochę dodatkowych informacji: użyj browserertools: // jako protokołu jak w //# sourceURL=browsertools://yourdomaingoeshere.com/action-openuwws.js

— dolbysurnd

6

Zwróć uwagę, że plik źródłowy pojawiający się w ten sposób w zakładce źródeł pojawi się w grupie (bez domeny) i jeśli chcesz go debugować, będziesz musiał dodać debugger;linię w swoim kodzie, sprawić, by ta linia została wykonana (zwykle w początek wykonywania pliku źródłowego), a następnie dodaj punkty przerwania w dowolnym miejscu.

W przypadku debugowania etapów produkcji, na których prawdopodobnie nie będzie żadnych debugger;wierszy w kodzie, możesz to zrobić, wykonując lokalną mapę za pomocą CharlesProxy do swojej „świeżej kopii pliku źródłowego z wstawioną linią debbugera”.

— Lluís Suñol
źródło

2

To mnie uratowało! Bez względu na to, co zrobiłem, plik nie pojawił się, dopóki nie wprowadziłem polecenia debugera. Po tym utrzymywało się przez ponowne ładowanie strony i sesje debugowania, nawet po usunięciu polecenia debugera.

— Mike Devenney

0

Próbując wyśledzić tego typu rzeczy w IE, otwieram narzędzia programistyczne (F12), a następnie znajduję, gdzie umieścić punkt przerwania, używając następującego wiersza w konsoli:

debugger;myFunction();

Spowoduje to przełączenie na kartę debugera, w której możesz wejść myFunction()i ustawić punkt przerwania.

— Alan Samet
źródło