Debuger

Będąc w każdej porządnej przeglądarce naciskamy klawisz F12, co włącza nam debugera.
Alternatywą jest kliknąć prawym przyciskiem myszy na dowolny element na stronie i wybrać z okienka "Zbadaj element" (inspect).
W niektórych przeglądarkach powyższa metoda może się nieco różnić (np. w Safari trzeba wcześniej włączyć narzędzia developerskie).

debuger

Co nam daje taki debuger?
Za jego pomocą możemy dowolnie badać elementy HTML na naszej stronie, zapisywać zmiany na stronie, edytować html, zarządzać localStorage, ciasteczkami, sprawdzać status, zmieniać style elementów, sprawdzać czemu dane elementy źle się wyświetlają, hackować internet itp.

My głównie będziemy korzystać z zakładek Elements (do badania elementów HTML) i zakładki Console, w której będziemy wypisywać badane elementy lub różne teksty. Do tego celu będziemy korzystać z komendy console.log(...), która wypisze dany tekst lub obiekt.
W całym kursie będziemy tą komendę wykorzystywać non stop, tak wiec nauczysz się jej czy tego chcesz czy nie.

Zakładka Console

Zakładka console służy do wypisywania komunikatów, odpalania tymczasowych skryptów, wywoływania kawałków kodu itp. W naszych skryptach bardzo często będziemy chcieli coś wypisać - np. jakiś komunikat, daną zmienną, dane elementu czy inną rzecz. Skorzystamy wtedy z instrukcji console.log, która służy właśnie do wypisywania w konsoli debugera różnych rzeczy:


    console.log('Witaj świecie'); //tekst pojawi się w zakładce Console debugera
    console.log(window); //w zakładce console wypisze obiekt, który od razu będziemy mogli zbadać klikając na strzałkę obok wypisanego obiektu
    console.log("Witaj", window, 100); //po przecinku możemy wypisać kilka elementów na raz

W wielu miejscach - nawet na tym kursie - będziesz chciał szybko sprawdzić działanie jakiegoś skryptu lub zmiennej.
Wystarczy więc, że otworzysz debugera (F12) i przejdziesz do zakładki konsoli (Console).
Jeżeli skrypt udostępnia jakieś zmienne lub metody, możesz w konsoli zacząć wpisywać ich nazwy, a debuger podpowie ci resztę.

Przejdź teraz do konsoli debugera i zacznij wpisywać:

mojaPie

Debuger powinien podpowiedzieć tobie pełną nazwę zmiennej mojaPierwszaSuperZmienna.
Strzałka w prawo by dopełnić wpisywaną nazwę i enter by wyświetlić w konsoli jej wartość.
W konsoli powinna pojawić się wartość tej zmiennej, czyli jakiś tekst. Jaki? Sprawdź sam. Podobnie możesz zacząć wpisywać window, Math czy podobne globalnie dostępne elementy.

Nie wszystkie zmienne będziemy mogli tak badać. Jeżeli dana zmienna jest ukryta przed zewnętrznym środowiskiem, nie zbadamy jej w powyższy sposób. Ale wtedy spokojnie możemy użyć console.log() bezpośrednio w kodzie.

Istnieje jeszcze kilka komend dla konsoli debugera:


    //tekst zwracający uwagę - pisany na żółtym tle i z wykrzyknikiem
    console.warn('Uwaga!');


    //tekst błędu - czerwony, na czerwonym tle
    console.error('Błąd!');


    //bardzo często będziemy chcieli wypisać szczegóły elementu czy obiektu
    //przykładowo gdy wypiszemy element pobrany ze strony, to pokaże nam tylko jego
    //znacznik w konsoli. Gdy chcemy wypisać więcej detali o tym obiekcie to
    //użyjemy console.dir
    console.dir(someButton);


    //grupowanie wielu tekstów (console.log etc) w konsoli w jedną grupę
    console.group('Nazwa grupy');
    console.log('Ala ma kota');
    console.log('Kot ma Alę');
    console.groupEnd(); //kończenie grupy


    console.groupCollapsed(); //grupa domyślnie zwinięta
    console.log('Ala ma kota');
    console.log('Kot ma Alę');
    console.groupEnd(); //kończenie grupy


    console.table([1,2,3,4,5]); //do przyjemnego wypisywania tablicy


    //czasami będziemy chcieli spradzić jak szybko wykona się nasz skrypt...
    console.time('Pierwszy test'); //rozpoczyna test - zaczyna liczyć czas
    for (let i=0; i<100000; i++) {}
    console.timeEnd('Pierwszy test'); //kończy test

    //czasami też będziemy chcieli zapauzować działanie skryptu w danym miejscu
    console.log(...);
    debuger; //przerywam działanie skryptu dzięki czemu mogę spokojnie go badać w zakładce Source

Ważną cechą console.log jest to, że możemy w niej wypisywać naście elementów po przecinkach. Dzięki temu nie będziemy musieli się skupiać na typach:


//zmiast
console.log("Nazywam się " + myName);

//lepiej użyć
console.log("Nazywam się", myName);

Zakładka Elements

belka debugera

Poza konsolą będziemy bardzo często korzystać z innych zakładek.
Pierwszą z nich jest zakładka Elements, która pozwala badać całą strukturę dokumentu.

Badany element możemy wybrać na kilka sposobów. Raz - wybierzemy go sobie właśnie w zakładce Elements. Możemy się po niej poruszać klikając na poszczególne elementy drzewka, lub posługując się strzałkami klawiatury (góra-dół, prawo-lewo rozwija i zwija element).
Druga opcja to użycie pierwszej z lewej strony górnej belki debugera ikonki.

ikonka wyboru elementów ze strony

Po jej wybraniu trzeba zaznaczyć badany element na stronie.
Trzecia opcja to kliknięcie badanego elementu na stronie prawym klawiszem myszki i wybranie opcji "zbadaj".

Widok debugera

Poza drzewem dokumentu zakładka Elements pokazuje po prawej stronie style każdego elementu. Style pokazywane są od dołu do góry. Te najbardziej aktualne (czyli występujące najniżej w stylach) są pokazane wyżej.

Na szarym tle pokazywane są style domyślne przeglądarki. Jeżeli któraś z właściwości będzie przekreślona, znaczy to, że inny selektor w css ją nadpisał (ma większą moc, lub dane stylowanie jest niżej w CSS). Czasami przy niektórych właściwościach mogą pojawić się wykrzykniki. Oznacza to, że dana właściwość została źle napisana.

debuger style

Po kliknięciu każdej właściwości po prawej stronie możemy ją dynamicznie zmieniać. Przy wartościach numerycznych możemy je zwiększać lub zmniejszać za pomocą klawiszy strzałek góra-dół. Wystarczy postawić kursor na danej wartości i strzałkami góra-dół zmienić jej wartość (z shiftem taka zmiana następuje co 10).

Przy niektórych właściwościach pojawiają się dodatkowe ikonki - np. służąca do wyboru koloru, lub do zmiany box-shadow.

Widok debugera

Kolejną bardzo ważną opcją jest :hov, który mieści się na górze z prawej strony tej zakładki. Umożliwia on wymuszenie stanu na elemencie - np. hover, focus, active itp. Bardzo ważna opcja przy tworzeniu efektów np. dla przycisków

Przećwiczmy powyższe informacje. Poniżej masz przycisk. Klient zgłosił, że przycisk wygląda, jakby został stworzony przez podludzi. Trzeba go poprawić.

Spróbuj teraz go zbadać i zmień jego parametry według poniższych wytycznych klienta:

  • Odstęp wewnętrzny (padding) ustaw na 20px 40px
  • Kolor przycisku (background) zmień na #e31a59
  • Kolor tekstu (color) zmień na #fff
  • Dodaj zaokrąglone rogi (border-radius) i ustaw je na 60px
Dodatkowo korzystając z ikonki :hov zmień stylowanie przycisku po najechaniu i ustaw mu parametry:
  • cień miał parametry: 0 2px 10px #7321f3
  • kolor tekstu : #fff
  • kolor tła przycisku: #7321f3

Zakładka Sources

Kolejną zakładką jest Sources. Znajdziesz tutaj wszystkie kody dołączonych plików - np. plików ze skryptami, stylami itp. wykorzystywanymi na danej stronie.

Po lewej stronie tej zakładki masz listę plików. Po wybraniu danego pliku, zobaczysz jego kod. Dla przykładu wybrałem plik scripts.min.js z tego kursu:

Zakładka Sources

Jak widzisz, kod tego pliku jest zminimalizowany. Jeżeli chciałbyś dokładniej go zbadać, musisz poprawić jego formatowanie. Służy do tego ikonka {} (Preety print) znajdująca się tuż pod kodem.

Po prawej stronie masz bardzo ważne ikonki służące do obsługi tak zwanych breakpointów. Co to jest? Nasz kod możemy badać nie tylko za pomocą console.log (które to działa bardzo dobrze), ale też właśnie za pomocą breakpointów.

ikony breakpointów

Patrząc na kod JavaScript w zakładce Source możemy klikając na liniach numerycznych zaznaczać linie, na których kod powinien się zatrzymać. Po odświeżeniu strony wykonywanie kodu zatrzyma się we wskazanych miejscach.
Od tej pory będziemy mogli badać każdą zmienną w kodzie. Wystarczy najechać na nią kursorem.

Dla testu znajdź w tej zakładce plik test-debuger.js i postaw tam kilka breakpointów. Następnie odśwież stronę i spróbuj pobadać kilka zmiennych.

Badanie zmienynch w debugerze

Po postawieniu breakpointów na liniach, odświeżeniu strony wczytywanie strony się zatrzyma, a sama strona zostanie przykryta szarym tłem. Zatrzymane miejsce będzie reprezentować niebieska linia w kodzie.
Za pomocą kursora możesz teraz badać wszystkie zmienne. Żeby wznowić działanie skryptów kliknij ikonkę play (pokazana powyżej) lub naciśnij klawisz F8. Skrypt się wznowi i ewentualnie zatrzyma na kolejnym breakpoincie.

Jak widzisz poza ikonką wznawiającą działanie skryptów mamy też kilka innych.

Wznawia działanie kodu
Przeskakuje wywołanie kolejnej funkcji (nie wchodzi do jej wnętrza) lub zachowuje się jak przejście do kolejnego kroku
Przechodzi do wnętrza kolejnej funkcji, lub zachowuje się jak przejście do kolejnego kroku
Wychodzi z danej funkcji i przechodzi do kolejnej linii kodu (czyli poza linię, gdzie dana funkcja została wywołana)
Wyłącza na chwilę breakpointy. Pomocne gdy mamy nastawiane naście takich breakpointów i chcemy na chwilę sprawdzić jak się strona zachowuje bez zatrzymywania
Czy kod ma się zatrzymywać na błędach

Kolejną ciekawą funkcjonalnością jest włączenie warunków dla danego breakpointu. Jak widzisz, domyślnie breakpointy są oznaczone kolorem niebieskim. Wyobraź sobie, że chciałbyś zbadać zmienną w pętli. Taka pętla wykonuje się 1000 razy. Ty chciałbyś sprawdzić zmienną nie przy każdym przebiegu pętli a tylko przy ostatniej iteracji pętli. Wystarczy więc dla takiego breakpointu postawić warunek. Klikamy prawym przyciskiem myszki na dany breakpoint i wybieramy "Edit breakpoint":

Edycja breakpoint

A następnie wpisujemy warunek, który musi być spełniony by dany breakpoint działał. W przypadku powyższego zadania było by to i === tab.length-1. Kolor breakpointa zmieni się na pomarańczowy i od tej pory kod będzie się zatrzymywał w tym miejscu tylko wtedy gdy dany warunek zostanie spełniony.

W przyszłości zapewne będziesz o wiele częściej korzystał z tej zakładki. Polecam ci przejść tutorial na stronie https://developers.google.com/web/tools/chrome-devtools/javascript/, który fajnie naucza korzystania z tej zakładki.

Zakładka Network

Skoro tak dobrze nam idzie omawianie zakładek, przechodzimy do kolejnej.

Zakładka newtwork służy do badania requestów. To właśnie tutaj możemy zbadać ile requestów musi być wykonane by nasza strona została wczytana (im mniej tym lepiej).
Dodatkowo możemy badać każdy request z osobna. Będziemy to robić szczególnie w dziale o ajaxie czy ciasteczkach.

Ciekawą opcją w tej zakładce jest możliwość symulowania wolnych łączy lub braku połączenia. Dzięki temu możemy sprawdzić jak nasza strona będzie się wczytywać na wolnych łączach.

Bardzo ważną opcją jest też opcja preserve log, którą znajdziesz na belce tej zakładki. Po jej włączeniu dane w tej zakładce nie będą czyszczone po odświeżeniu strony, a tylko doklejane do już wypisanych. Dzięki temu łatwiej nam będzie badań np. połączenia formularzy. Gdybyśmy tej opcji nie zaznaczyli, po wysłaniu formularza strona by się odświeżyła i nie zobaczylibyśmy błędów, które po odświeżeniu zostały wyczyszczone.

Dodatkowo na górze tej zakładki znajdują się opcje pozwalające filtrować requesty. Przydatne gdy chcemy np. wyszukać tylko pliki ze stylami dołączonymi do strony.

debuger network bar

Zakładka Application

Zakładka application

Zakładka Application pozwala nam badać różne miejsca gdzie przechowywane są dane dostępne dla strony. I tak możemy tutaj zbadać czy usunąć ciasteczka czy dane z localStorage. Będziemy tutaj zaglądać w działach z localStorageczy ciasteczkami.

Zakładka Audits

Ostatnia zakładka jaką chciałbym omówić to zakładka Audits.

Istnieje taka strona jak https://developers.google.com/speed/pagespeed/, która służy do sprawdzania strony pod względem dostępności, szybkości wczytywania itp.

Po jej użyciu dostaniemy raport, który będzie zawierał różne porady co powinniśmy poprawić na naszej stronie.

Raportu takiego nie należy traktować jako wyznacznika dobrej strony. To tylko porady jak zoptymalizować działanie naszej strony. Czasami lepsze, czasami gorsze. 100 pkt wcale nie będzie oznaczać, że nasza strona jest idealna i że odniesie sukces. 100pkt oznacza, że na google pagespeed uzyskaliśmy maksimum punktów. Nic więcej to nie oznacza.

Ale też warto korzystać z takich stron. Czasami zapomnimy o minimalizacji skryptów, o optymalizacji CSS, o zmniejszeniu wagi grafik itp. Google page speed może nam o tym przypomnieć.

W zakładce Audits możemy przeprowadzić podobne sprawdzenie i dostaniemy całkiem podobne wyniki - nie tylko tyczące się optymalizacji, ale też dostępności czy bezpieczeństwa.

debuger zakładka audits

Jak widzisz, w momencie pisania tego tekstu ta strona nie jest najlepiej zoptymalizowana. Ale obiecuję - kiedyś to poprawię...

Istniej więcej - może nawet lepszych stron - przeznaczonych do podobnych testów. Ja polecam korzystać z https://www.webpagetest.org/ która daje ciekasze raporty od google page speed. Jeżeli zaś chodzi o accessibility, warto zapoznać się z http://wave.webaim.org/

Dodatkowe narzędzia

O debugerze można by napisać całkiem sporą książkę, bo narzędzie to ma pełno ukrytych funkcjonalności. Praktycznie w każdym edytorze istnieje skrót Ctrl + Shift + P (w phpStorm i webSotrm Ctrl + Shift + A), które pokazuje okienko, które umożliwia wyszukiwanie praktycznie każdej opcji w danym edytorze.
Dla przykładu chcemy włączyć/wyłączyć zawijanie tekstu w danym oknie? Ctrl + Shift + P, wypisuję Word Wrap (lub Soft wrap w Webstorm) i naciskam enter. Podobnie można właczyć podział okna (wpisując Split) itp.

W debugerze też istnieje podobny skrót, który służy do tego samego.

Wśród dodatkowych ciekawych narzędzi warto spojrzeć na Animation, która to służy do badania animacji na stronach, Remote devices, która służy do podłączania dodatkowych urządzeń, czy chociażby Rendering, która służy do sprawdzania jak rysowana jest nasza strona.