В какой-то момент пути молодого веб-разработчика первоначальный набор инструментов отладки, таких как отладчик и console.log, перестанет быть достаточным для выполнения работы.

В этой статье рассматриваются некоторые базовые функции отладки Chrome, доступные с помощью инструментов Dev, которые я обнаружил при изучении fetch API.

Проблема

Представьте, если хотите, наивного разработчика Javascript (не знаю, кто…), только что перешедшего с Ruby, готового согнуть крылья с помощью простого веб-приложения JS. Приложение использует выборку, чтобы обращаться к API json-сервера, манипулировать некоторыми данными и отображать дополнительные узлы dom, когда пользователь добавляет элементы данных или манипулирует ими.

Представьте волнение этого разработчика, когда он приближается к завершению разработки приложения, наконец-то запустив желаемую функциональность рендеринга — только для того, чтобы все визуализированные элементы исчезли при перезагрузке страницы. Без подсказки. (Примечание: это было связано с событием нажатия кнопки в Chrome, а не с отправкой формы без .preventDefault()).

Цепочка мыслей автоматического разработчика очереди:

«Что! Обновление?! Я тщательно продумала организацию и объем своих функций. Я распутал и организовал своих слушателей событий. Разделение ответственности, минимизация зависимостей и т. д. и т. д. Я защищен от неожиданного поведения плохо организованного Javascript строгими принципами объектно-ориентированного программирования. Кроме того, в моих файлах нет кода, который вызывал бы какое-либо уничтожение данных, очистку html или обновление страницы. Компьютер неисправен!

Ладно, ладно… компьютер всегда прав… давайте разберемся».

Введите console.log и оставшуюся часть отладчика. Эти стандартные инструменты обычно все, что мне нужно, но в этом случае возникла проблема. Страница «обновлялась», или я так думал, потому что консоль стиралась вместе с моим JS-контентом.

Размещение console.log и отладчика в моем коде было бесполезным. Я прошелся по своим функциям везде, где размещал отладчик и исследовал, но все работало, как и ожидалось. Где-то между работой, как и ожидалось, и обновлением, что-то… происходило.

Мне нужен был микроскоп, а у меня была только лупа. Мне нужно было больше данных и разные инструменты для их получения. Когда я понял это, мой взгляд медленно с тревогой обратился к вкладке «Сеть» инструментов разработчика. Неизведанная территория. Грозовые тучи на горизонте. «Сеть»… хммм, да, это кажется правильным… звучит технически. Если есть обновление, и оно не исходит из моего кода, возможно, что-то в цикле запрос/ответ вызывает его. «Сеть» должна иметь дело с этим, верно?

Советы по работе с вкладкой «Сеть»

Сохранить журнал

Путешествие по Google привело меня к моему первому наиболее полезному совету при использовании Chrome Dev Tools: журнал сохранения. На вкладке «Сеть» к журналу сохранения можно получить доступ в верхней части инструментов разработчика.

Если этот флажок установлен, сетевой журнал сохраняется при обновлении страниц и навигации. Хип-хип-массив! Возьмите это — инвазивное обновление! Наконец-то у меня появились данные для исследования… почти.

Используйте большие строки запроса

Расположенные непосредственно справа от представления: метка параметров, большие строки запроса позволяют просматривать некоторые дополнительные, но очень полезные данные, включая маршрут и инициатора каждого запроса. Журналы показали, что у меня был запрос на начальный DomContentLoaded, а затем на нажатие кнопки. Оба они были ожидаемы и инициированы строками в моем коде Javascript. Затем таинственным образом был инициирован запрос на получение индексной страницы из «Другого». Инопланетяне. Я, наконец, нашел событие, вызвавшее мои страдания, но я все еще не имел ни малейшего представления о причине. Мне нужно было… больше силы…

Установите точки останова и начните шагать!

Бывает ли у вас когда-нибудь такой момент, когда вы думаете, чувак… было бы очень хорошо, если бы я мог сделать X прямо сейчас… и затем ваша немедленная мысль, что я думаю, что кто-то, вероятно, разработал это? Какое время быть разработчиком программного обеспечения.

Чтобы выяснить проблему с моим кодом, мне нужно было получить более подробную информацию и пройтись по коду, строка за строкой. Это именно то, что позволяют сделать точки останова и пошаговая функциональность Dev Tools. Точки останова приводят к остановке выполнения кода и предоставляют вам информацию о текущем контексте выполнения и области действия вашего кода.

Вы, вероятно, знакомы с построчными точками останова (что делает для вас размещение отладчика в вашем коде), но в Dev Tools есть много других полезных опций, когда размещение отладчика везде слишком утомительно. Два из них, с которыми я лучше всего познакомился, — это точки останова прослушивателя событий и точки останова XHR/fetch.

Точки останова прослушивателя событий

Точки останова прослушивателя событий позволяют вам добавлять точки останова на основе огромного количества событий, лишь некоторые из которых включают щелчок, нажатие клавиши, отправку и, что важно для меня, DOMContentLoaded.

XHR/выборка точек останова

Одной из проблем, с которыми я столкнулся, было расследование того, что происходит с моими выборками. В итоге это была точка останова XHR/fetch, из которой я смог пройтись по коду и в конечном итоге определить проблему.

Когда точка останова активирована, пользователю становятся доступны некоторые полезные инструменты. Инструмент разработчика обращается к координатам кода, достигшего точки останова, и дает вам инструменты для пошагового выполнения кода. На следующем рисунке я активировал точку останова при получении патча:

Переход через функции, вход и выход из них

Точки останова Dev Tool отлично подходят для предоставления вам контекста и аналитических инструментов для понимания вашего кода. Как только точка останова активирована, вы можете проходить через функции, выходить из них, входить в них и проходить через них. Звучит как танец… посмотрим, как это выглядит на практике.

Переход к функциям (со страниц поддержки Google)

  • Step Over: выполнить функцию, не заходя в нее, и сделать паузу в следующей точке останова.
  • Step Into: если следующая строка содержит вызов функции, Step Into перейдет к этой функции и приостановит ее на первой строке.
  • Step Out: выполняет оставшуюся часть текущей функции, а затем делает паузу на следующем операторе после вызова функции.
  • Шаг: пройдитесь по коду по одной функции за раз.
  • Деактивировать точки останова: временно отключает все точки останова. Используйте для возобновления полного выполнения без фактического удаления точек останова. Нажмите еще раз, чтобы снова активировать точки останова.
  • Длинное возобновление/возобновление: они позволяют пропустить остальную часть кода, несмотря на точки останова (ну… в течение 500 мс) или перейти к следующей точке останова соответственно.

Чтобы перейти от кода к следующему вызову функции, я сначала нажал кнопку шага:

И…. Ура!!!! Я наконец нашел проблему. Перезагрузка. Следующая функция, которую нужно было выполнить после моей выборки, выполнялась в строке 46 файла index.html. Спасибо, DevTools.

Однако была проблема. В моем файле было всего 22 строки html-кода.

Обратите внимание на координаты кода в левом нижнем углу окна просмотра кода… как здорово

Была причина, по которой я не мог найти обновление в своем коде — его не было в моем коде. Он вводился расширением VS Code для живого сервера, которое я использовал. Без моего ведома (первый и последний раз, когда я когда-либо буду использовать инструмент, который я не совсем понимаю… ха… ха…), когда я открываю файлы index.html с помощью живого сервера, он запускает соединение через веб-сокет.

Очередь 2-часовая кроличья нора, потраченная на исследование веб-сокетов. Само собой разумеется — я всегда думал, что это просто стандартный способ просмотра ваших веб-сайтов с помощью VS Code. Я быстро загрузил другое расширение, чтобы открывать html-файлы в своем браузере без веб-сокетов, и все было решено.

У обоих были большие проблемы, и их не было вовсе.