Chrome DevTools część 2 – Event Listeners

Czas na kolejną funkcję DevToolsów, o której zawsze wiedziałem, że jest, ale nigdy jej nie użyłem, czyli Event Listeners.

Prosty przykład

Zakładka event listeners, jak nietrudno się domyślić, pozwala na przeglądanie javascriptowych eventów zbindowanych do danego elementu.

Zacznijmy klasycznie od prostego przypadku. Przygotowałem w tym celu mały przykład:

<html>
<head>
<meta charset="utf-8">
<title>Event handlers demo</title>
<script src="http://code.jquery.com/jquery-latest.js" type="text/javascript"></script>
</head>
<body>
<div class="wrapper" style="width:300px;height:300px;background:red;">
<button>Click me</button>
</div>
<script>
(function() {
$('.wrapper').click(function wrapperHandler() {
console.log('wrapper');
});
$('button').click(function buttonHandler() {
console.log('button');
});
})();
</script>
</body>
</html>

view raw
index.html
hosted with ❤ by GitHub

Po otwarciu zakładki Event Listeners dla wrappera widzimy event handler dodany przez mój kod:

Zrzut ekranu 2017-06-13 o 21.36.48.png
Listener dla wrappera

Zobaczmy teraz co zostanie wyświetlone dla elementu button:

Zrzut ekranu 2017-06-13 o 21.47.28.png
Listenery dla guzika

Co tu się odjaniepawliło? Skąd listener wrappera w listenerach buttona? Okazuje się, że Chrome domyślnie pokazuje listenery nie tylko dla wybranego elementu, ale również dla jego przodków w drzewie. Odzaczenie checkboxa Ancestors spowoduje odfiltrowanie listenerów przodków.

Czas pobrudzić sobie ręce

Wszystko wydaje się proste, a jednak przy próbie podejrzenia event listenerów dla prostego guzika w Emberowej aplikacji zastałem następujący widok:

Zrzut ekranu 2017-06-11 o 21.12.25
Początkowa lista listenerów
Wklejony_obraz_13_06_2017__23_05
Wybrany guzik

Dziwne, skąd tyle listenerów zbindowanych do prostego przycisku? Ok, zobaczmy co stanie się po odznaczeniu Ancestors:

Zrzut ekranu 2017-06-11 o 21.52.21
Lista listenerów po odznaczeniu opcji „Ancestors”

Odznaczenie opcji Ancestors ograniczyło nieco liczbę listenerów, jednak wciąż jest ona dość duża jak na przycisk. Tutaj z pomocą przychodzi checkbox Framework Listeners. Po odznaczeniu tej opcji odfiltrowane zostały listenery dodane przez bibliotekę Ember.js, dzięki czemu w końcu znalazłem konkretny listener zbindowany przez mój własny kod do przycisku.

Zrzut ekranu 2017-06-11 o 21.56.16
Event listener zdefiniowany przez naszą aplikację

Event listener breakpoints

Ok, fajnie, wiem już, że do mojego przycisku przypisany jest event handler. Spróbujmy teraz wykorzystać Event listener breakpoints w zakładce Sources aby sprawdzić handler w akcji. Na rozwijanej liście zaznaczamy mouse -> click, dzięki czemu kliknięcie w dowolny element ze zdefiniowanym handlerem dla eventu click spowoduje wstrzymanie wykonania kodu.

Zgodnie z oczekiwaniami kliknięcie w przycisk spowodowało odpalenie debuggera. Kod zatrzymał się jednak w niezbyt interesującym miejscu – we wrapperze dodanym przez zewnętrzną bibliotekę (new relic). Można sobie z tym poradzić poprzez kliknięcie prawym przyciskiem w oknie debuggera i wybranie opcji Blackbox script.

Zrzut ekranu 2017-06-13 o 23.12.41.png
Dodawanie skryptu do listy „Blackboxed scripts”

Po dodaniu odpowiednich wpisów do listy blackboxed scripts i ponownym kliknięciu w guzik debugger odpalił się już w miejscu, które mnie interesowało:

Wklejony_obraz_13_06_2017__23_22
Breakpoint w poprawnym miejscu

Monitorowanie zdarzeń

W przypadku, gdy nie interesuje nas jak zostało obsłużone pewne zdarzenie, a jedynie czas jego wywołania przydatna może okazać się funkcja monitorEvents. W inspectorze należy zaznaczyć interesujacy element, a następnie wpisać:

monitorEvents($0)

każde zdarzenie, które wystąpi dla zaznaczonego elementu zostanie zalogowane w konsoli:

Zrzut ekranu 2017-06-13 o 23.34.39
Logowanie zdarzeń przy uzyciu monitorEvents

Monitorowanie można ograniczyć też do konkretnych eventów, podając nazwę zdarzenia w drugim parametrze funkcji:

monitorEvents($0, ‚click’)

Monitorowanie można zakończyć używając polecenia:

unmonitorEvents($0)

Bonus

Jeśli korzystamy z biblioteki jQuery, to szczegóły event handlerów dla aktualnie wybranego elementu możemy podejrzeć wpisując

$._data(($0), ‚events’)

Zrzut ekranu 2017-06-13 o 23.42.40.png
Lista event handlerów w jQuery

Czasami ten sposób może okazać się szybszy niż przekopywanie się przez zakładkę Event listeners.

Podsumowanie

W tym poście zaprezentowałem kilka sposobów na analizę zdarzeń za pomocą Chrome DevTools. Dowiedzieliśmy się, jak przeglądać listę event listenerów, ustawiać automatyczne breakpointy dla event listenerów oraz jak włączyć logowanie zdarzeń dla elementów drzewa.

W kolejnym poście serii przeanalizuję temat DOM breakpoints.

Chrome DevTools część 1 – wstęp

Zgodnie z zapowiedzią – rozpoczynam serię wpisów o Chrome DevTools. Seria ta jest skierowana do osób, dla których Chromowe narzędzia nie są nowością, ale, tak jak ja, czują, że nie wykorzystują w pełni potencjału jaki oferują. Postaram się omówić i przedstawić na przykładach opcje i zakładki, z którymi webdeveloperzy nigdy „nie mają czasu” się zapoznać.

Pierwszy temat, którym się zajmiemy to zakładka Elements. Przez większość osób jest ona używana jedynie do podglądania drzewa dokumentu HTML lub zmieniania/dodawania reguł CSS.

Powiem o kilku rzeczach, które nie były dla mnie oczywiste na pierwszy rzut oka oraz takich, do których bałem się zbliżyć, bo wydawały mi się zbędne 🙂

Na rozgrzewkę wrzucam coś super prostego i większość z Was pewnie mnie w tym momencie wyśmieje, ale nigdy nie zwróciłem na to uwagi. Otóż, pod drzewkiem HTML jest belka (tzw. breadcrumbs), która umożliwia łatwą nawigację pomiędzy rodzicami aktualnie wybranego elementu drzewa. Zamiast tego zawsze mozolnie klikałem w elementy drzewa…

Mind blown.

breadcrumbs

Kolejny post będzie już bardziej dojrzały. Przedstawię jak i kiedy używać zakładki Event listeners.