Wprowadzenie
Obecnie autorzy mogą korzystać z wielu abstrakcji do tworzenia aplikacji internetowych. Zamiast bezpośrednio korzystać z interfejsów API niskiego poziomu, które udostępnia platforma internetowa, wielu autorów korzysta z ramek, narzędzi do kompilacji i kompilacji, aby pisać aplikacje z perspektywy wyższego poziomu.
Na przykład komponenty tworzone na podstawie platformy Angular są tworzone w TypeScript z użyciem szablonów HTML. W tle interfejs wiersza poleceń Angulara i webpack kompilują wszystko do JavaScriptu i do tak zwanego pakietu, który jest następnie wysyłany do przeglądarki.
Podczas debugowania lub profilowania aplikacji internetowych w DevTools możesz obecnie wyświetlać i debugować skompilowaną wersję kodu zamiast kodu, który został faktycznie napisany. Jako autor nie chcesz jednak, aby tak się stało:
- Nie chcesz debugować zminifikowanego kodu JavaScript, tylko oryginalny kod JavaScript.
- Korzystając z TypeScript, nie musisz debugować kodu JavaScript, tylko oryginalny kod TypeScript.
- Gdy używasz szablonów, np. w przypadku Angulara, Lit lub JSX, nie zawsze musisz debugować wynikowy DOM. Możesz debugować same komponenty.
Ogólnie rzecz biorąc, debugowanie własnego kodu warto przeprowadzać w miarę jego pisania.
Mapy źródeł już w pewnym stopniu wypełniają tę lukę, ale Narzędzia deweloperskie w Chrome i ekosystem mają jeszcze więcej do zaoferowania w tej dziedzinie.
Przyjrzyjmy się im bliżej.
Kod autoryzowany a wdrożony
Obecnie podczas poruszania się po drzewie plików w panelu źródeł możesz zobaczyć zawartość skompilowanego i często zminiaturyzowanego pakietu. To są rzeczywiste pliki, które przeglądarka pobiera i uruchamia. W Narzędziach deweloperskich nazywamy to wdrożonym kodem.
Nie jest to wygodne i często trudne do zrozumienia. Jako autor chcesz wyświetlić i przeprowadzić debugowanie kodu, który napisałeś, a nie wdrożonego kodu.
Aby to zrekompensować, możesz teraz wyświetlić w drzewie kod autorski. Dzięki temu drzewo będzie bardziej przypominać pliki źródłowe widoczne w IDE, a pliki te będą teraz oddzielone od wdrożonego kodu.
Aby włączyć tę opcję w Narzędziach deweloperskich Chrome, kliknij Ustawienia > Eksperymenty i zaznacz pole wyboru Grupuj źródła w drzewa Autoryzowane i Wdrożone.
„Tylko mój kod”
Podczas korzystania z zależności lub tworzenia na podstawie frameworku mogą Ci przeszkadzać pliki innych firm. Większość czasu chcesz widzieć tylko swój kod, a nie kod biblioteki zewnętrznej ukrytej w folderze node_modules.
Aby to zrekompensować, w Narzędziach deweloperskich jest domyślnie włączone dodatkowe ustawienie: Automatycznie dodawaj znane skrypty innych firm do listy ignorowanych. Znajdziesz go w sekcji Narzędzia dla programistów > Ustawienia > Lista ignorowania.
Gdy to ustawienie jest włączone, DevTools ukrywa wszystkie pliki i foldery, które zostały oznaczone przez framework lub narzędzie do kompilacji jako do zignorowania.
Od wersji Angular 14.1.0 zawartość folderów node_modules i webpack została oznaczona jako taka. Dlatego te foldery, pliki w nich i inne tego typu elementy zewnętrzne nie pojawiają się w różnych miejscach w DevTools.
Jako autor nie musisz nic robić, aby włączyć tę nową funkcję. Implementacja tej zmiany zależy od platformy.
.Kod z listy ignorowanych w wyświetleniach stosu
Pliki z listy ignorowanych nie pojawiają się już w śladach stosu. Jako autor możesz teraz zobaczyć więcej trafnych ścieżek pakietu.
Jeśli chcesz zobaczyć wszystkie ramki wywołania w wyświetleniu stosu, możesz kliknąć link Pokaż więcej ramek.
To samo dotyczy stert wywołań, które widzisz podczas debugowania i przechodzenia przez kod. Gdy frameworki lub pakietatory informują DevTools o skryptach innych firm, DevTools automatycznie ukrywa wszystkie nieistotne ramki wywołania i podczas debugowania krok po kroku pomija kod z listy ignorowanych.
Kod z listy ignorowanych w drzewie plików
Aby ukryć pliki i foldery z listy ignorowanych z drzewa plików Kod autora w panelu Źródła, zaznacz Ukryj kod zignorowany w widoku drzewa źródeł w sekcji Ustawienia > Eksperymenty w DevTools.
W tym przykładowym projekcie Angulara foldery node_modules i webpack są teraz ukryte.
Kod na liście ignorowanych w menu „Otwórz szybko”
Kod z listy ignorowanych nie tylko nie jest widoczny w drzewie plików, ale też nie jest widoczny w menu „Otwórz szybko” (Control + P (Linux/Windows) lub Command + P (Mac)).
Więcej ulepszeń ścieżek stosu
Po omówieniu istotnych zrzutów stosu Narzędzia deweloperskie Chrome wprowadzają jeszcze więcej ulepszeń zrzutów stosu.
Połączone zrzuty stosu
Gdy niektóre operacje są zaplanowane do wykonania asynchronicznie, ścieżki stosu w DevTools pokazują obecnie tylko część informacji.
Oto na przykład bardzo prosty harmonogram w hipotetycznym pliku framework.js:
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
tasks.push({ f });
},
work() {
while (tasks.length) {
const { f } = tasks.shift();
f();
}
},
};
}
const scheduler = makeScheduler();
function loop() {
scheduler.work();
requestAnimationFrame(loop);
};
loop();
…i jak deweloper może go używać we własnym kodzie w pliku example.js:
function someTask() {
console.trace("done!");
}
function businessLogic() {
scheduler.schedule(someTask);
}
businessLogic();
Po dodaniu punktu przerwania w metodie someTask lub podczas sprawdzania śladu wydrukowanego w konsoli nie widzisz żadnej wzmianki o wywołaniu funkcji businessLogic(), która była „przyczyną pierwotną” tej operacji.
Zamiast tego w śladzie pakietu widzisz tylko logikę planowania, która doprowadziła do wykonania zadania. Nie ma w nim jednak informacji o powiązaniach przyczynowo-skutkowych między zdarzeniami prowadzącymi do tego zadania.
Dzięki nowej funkcji o nazwie „Tagowanie kodu asynchronicznego” można jednak przekazać całą historię, łącząc obie części kodu asynchronicznego.
Interfejs API otagowania asynkronicznej talii wprowadza nową metodę console o nazwie console.createTask(). Podpis API ma postać:
interface Console {
createTask(name: string): Task;
}
interface Task {
run<T>(f: () => T): T;
}
Wywołanie console.createTask() zwraca instancję Task, której można później użyć do wykonania treści zadania f.
// Task Creation
const task = console.createTask(name);
// Task Execution
task.run(f);
Zadaniem jest połączenie kontekstu, w którym zostało utworzone, z kontekstem wykonywanej funkcji asynchronicznej.
W przypadku funkcji makeScheduler z powyższego kodu kod będzie wyglądał tak:
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
const task = console.createTask(f.name);
tasks.push({ task, f });
},
work() {
while (tasks.length) {
const { task, f } = tasks.shift();
task.run(f); // instead of f();
}
},
};
}
Dzięki temu Narzędzia deweloperskie w Chrome mogą teraz wyświetlać lepszy ślad stosu.
Zwróć uwagę, że businessLogic() jest teraz uwzględnione w wyświetleniu ścieżki wywołań. Co więcej, zadanie ma znajomą nazwę someTask zamiast ogólnego requestAnimationFrame.
Ramki przyjaznych rozmów
Podczas tworzenia projektu frameworki często generują kod z różnych języków szablonów, takich jak Angular czy szablony JSX, które przekształcają kod podobny do kodu HTML w zwykły kod JavaScript, który ostatecznie działa w przeglądarce. Czasami tego typu wygenerowane funkcje mają nazwy, które nie są zbyt przyjazne – albo nazwy jednoliterowe po ich zminimalizowaniu, albo niejasne lub nieznane nazwy, nawet jeśli nie są one zminimalizowane.
W przykładowym projekcie jest to funkcja AppComponent_Template_app_button_handleClick_1_listener, która pojawia się w zrzucie stosu.
Aby rozwiązać ten problem, narzędzia deweloperskie w Chrome obsługują teraz zmianę nazwy tych funkcji za pomocą map źródłowych. Jeśli mapa źródłowa zawiera wpis z nazwą początku zakresu funkcji, ramka wywołania powinna wyświetlać tę nazwę w wyświetleniu stosu.
Jako autor nie musisz nic robić, aby włączyć tę nową funkcję. Implementacja tej zmiany zależy od platformy.
Perspektywy
Dzięki dodatkom opisanym w tym poście możesz łatwiej debugować w Narzędziach deweloperskich w Chrome. Zespół chce zbadać jeszcze inne obszary. W szczególności chodzi o to, jak ulepszyć profilowanie w Narzędziach deweloperskich.
Zespół Chrome DevTools zachęca autorów frameworków do korzystania z tych nowych funkcji. W studium przypadku: ulepszone debugowanie Angulara za pomocą Narzędzi dla deweloperów znajdziesz wskazówki dotyczące implementacji.