Отладка js в браузере

Обновлено: 08.07.2024

В каждом современном браузере есть свои инструменты, и хотя они могут отличаться интерфейсом или некоторыми специфическими возможностями, основной функционал для отладки программы у них схожий. Поэтому понимание процесса отладки в рамках даже одного браузера позволит сформировать общее представление об отладке в других браузерах. Полную документацию по Инструментам Разработчика для браузера Firefox можно найти в документации MDN, а для браузера Chrome (на английском) в документации Chrome DevTools.

Поэтапный процесс отладки программы

Есть несколько способов открыть на странице Консоль Разработчика:

Клавиатура. Ctrl + Shift + I, кроме

Internet Explorer. (клавиша - F12)
Mac OS X. (сочетание клавиш - ⌘ + ⌥ + I )

Настройка и управление (кнопка справа вверху браузера) > Дополнительные инструменты > Инструменты разработчика

Нажмите правой кнопкой мыши на любом участке веб-страницы (Ctrl-клик для Mac), появится контекстное меню, в котором Вам нужно выбрать пункт “Посмотреть код” (при этом отобразится код того элемента, на котором вы щёлкнули правой кнопкой)

В открывшейся Консоли есть набор вкладок, каждая из которых предоставляет определенный функционал. На начальном этапе достаточно иметь представление о следующих вкладках:

Первой является вкладка Инспектор (или Elements в браузере Chrome), где отображается разметка страницы и стили элементов справа.

Эта панель имеет косвенное отношение к процессу отладки JavaScript, поэтому детально в этой статье разбираться не будет. Подробную информацию по ней лучше изучить в соответствующей документации.

Следующей вкладкой в Инструментах Разработчика является панель Консоль (или Console в браузере Chrome), которая отображает логи работы программы. Например, ошибки, предупреждения, и другую дополнительную информацию, которую генерирует программа JavaScript в ходе своего выполнения. А также эта панель позволяет непосредственно взаимодействовать с кодом JavaScript на странице.

Все возникшие ошибки в JavaScript коде, выводятся в ней с указанием файла и конкретного места в нем, где произошла ошибка.

Третьей вкладкой является панель Отладчик (или Sources в Chrome). Эта панель по сути представляет собой встроенную среду разработки кода, в которой можно получить доступ ко всем подключенным к странице файлам. Можно посмотреть их содержимое, отследить их выполнение, а в Chrome еще можно отредактировать код, скопировать его или сохранить изменения в новом файле.

Также, для отладки кода в этой панели используются точки останова (брейкпоинты), которые позволяют приостановить выполнение кода на определенной строке. Поставить точку останова можно кликнув на номер соответствующей строки или написав в самом коде ключевое слово debugger;

Управлять потоком выполнения программы после остановки на точке можно с помощью кнопок, расположенных справа в верхнем углу консоли. Которые позволяют возобновить выполнение ( F8 ), перешагнуть выполнение до следующей точки останова ( F10 ), зайти в функцию ( F11 ) или выйти из неё ( Shift F11 ). Крайняя кнопка, если её активировать, позволяет приостанавливаться на каждом непойманном исключении.

Воспроизведение и поиск ошибок

Первым шагом отладки является воспроизведение ошибки. В данном случае, ошибка воспроизводится при самом запуске программы, так как на странице не отображается необходимое содержание.

Точки останова

Несмотря на исправление строки, вызывающей исключение, содержание страницы не изменилось. Поэтому следующим этапом будет отладка программы с помощью точек останова.

В программе есть функция buggy() , которая должна добавлять картинку и изменять заголовок. Но её выполнению не приводит к нужному результату, хотя никакого больше исключения код не вызывает. Это значит, что скорее все проблема кроется в самой логике этой функции.

Как говорилось выше есть два способа поставить точку останова: кликнув по номере строки в отладчике или написав на нужной строке в коде ключевое слово debugger; .

Воспользуемся первым способом — поставим точку останова на 20-й строке, где вызывается нужная функция. Обновив страницу в браузере, чтобы зайти в эту функцию нужно нажать соответствующую кнопку или клавишу ( F11 ).

При этом в правой части панели в блоке “Области” можно отслеживать значения переменных. В данном случае в переменной param содержится значение "Show" , хотя в этой функции, для изменения содержимого страницы, этот параметр должен начинаться с маленькой буквы. Поэтому, для корректной работы программы, нужно изменить входной параметр в вызове функции на "show"

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

Но по умолчанию в браузере ошибки не видны. То есть, если что-то пойдёт не так, мы не увидим, что именно сломалось, и не сможем это починить.

Для решения задач такого рода в браузер встроены так называемые «Инструменты разработки» (Developer tools или сокращённо — devtools).

Chrome и Firefox снискали любовь подавляющего большинства программистов во многом благодаря своим отменным инструментам разработчика. Остальные браузеры, хотя и оснащены подобными инструментами, но все же зачастую находятся в роли догоняющих и по качеству, и по количеству свойств и особенностей. В общем, почти у всех программистов есть свой «любимый» браузер. Другие используются только для отлова и исправления специфичных «браузерозависимых» ошибок.

Для начала знакомства с этими мощными инструментами давайте выясним, как их открывать, смотреть ошибки и запускать команды JavaScript.

Google Chrome

В её JavaScript-коде закралась ошибка. Она не видна обычному посетителю, поэтому давайте найдём её при помощи инструментов разработки.

Нажмите F12 или, если вы используете Mac, Cmd + Opt + J .

По умолчанию в инструментах разработчика откроется вкладка Console (консоль).

Она выглядит приблизительно следующим образом:

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

Обычно при нажатии Enter введённая строка кода сразу выполняется.

Чтобы перенести строку, нажмите Shift + Enter . Так можно вводить более длинный JS-код.

Теперь мы явно видим ошибки, для начала этого вполне достаточно. Мы ещё вернёмся к инструментам разработчика позже и более подробно рассмотрим отладку кода в главе Отладка в браузере Chrome.

Firefox, Edge и другие

Инструменты разработчика в большинстве браузеров открываются при нажатии на F12 .

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

Safari

Safari (браузер для Mac, не поддерживается в системах Windows/Linux) всё же имеет небольшое отличие. Для начала работы нам нужно включить «Меню разработки» («Developer menu»).

Откройте Настройки (Preferences) и перейдите к панели «Продвинутые» (Advanced). В самом низу вы найдёте чекбокс:

Теперь консоль можно активировать нажатием клавиш Cmd + Opt + C . Также обратите внимание на новый элемент меню «Разработка» («Develop»). В нем содержится большое количество команд и настроек.

Итого

Инструменты разработчика позволяют нам смотреть ошибки, выполнять команды, проверять значение переменных и ещё много всего полезного.
В большинстве браузеров, работающих под Windows, инструменты разработчика можно открыть, нажав F12 . В Chrome для Mac используйте комбинацию Cmd + Opt + J , Safari: Cmd + Opt + C (необходимо предварительное включение «Меню разработчика»).

Теперь наше окружение полностью настроено. В следующем разделе мы перейдём непосредственно к JavaScript.

Очень много сервисов сейчас позволяют дебажить код над фронтенде. Chrome DevTools и Firefox Developer Tools среди них самые популярные, но и в других браузерах тоже есть свои тулзы. Мы будем использовать Chrome DevTools для примеров.

Дебажим JavaScript

Откровенно говоря, отладка кода может занимать много времени. Особенно, если использовать такие простые команды как console.log() или window.alert().

Нужно писать, а потом удалять дополнительный код, а иногда эти команды все равно попадают в коммит (даже если вы думали, что все их забрали). А если при этом использовать линты (статические отладчики), то команды console или alert будут подсвечиваться в коде.

И на этом моменте в игру вступает Chrome DevTools, позволяя нам дебажить код без утомительных команд. Среди фишек этой тулзы, редактирование CSS и HTML, тестирование сети и проверка скорости сайта — наши любимые.

Чтобы на практике познакомиться с этой тулзой, давайте создадим простенькую страничку на JavaScript с getData() методом. Этот метод будет просто собирать данные с поля ввода, создавать DOM элемент с dataSpan ID и добавлять значение с поля ввода в этот элемент.

Вот как наша страничка будет выглядеть:

В JavaScript:

Сохраним ее как app.js.

Вот как наша страничка будет выглядеть в браузере:

Чтобы проверить как метод работает до того, как сохранять данные в dataSpan, можно использовать старомодные console.log(data) или window.alert(data). Вот что мы увидим запустив файл в VS Code:

Это самый примитивный подход.

Вместо этого, мы используем брейкпоинты (точки останова) вChrome DevTools чтобы убедиться, что все работает как надо.

Брейкпоинт — это строка кода, на которой мы хотим приостановить прогонку кода, чтобы изучить как он работает (или не работает).

Возвращаясь к примеру, давайте запустим страницу в Google Chrome и сделаем следующее:

Чтобы открыть Chrome Developer Tools, в правом верхнем углу браузера, кликнем чтобы открыть меню настроек.
В этом меню, выберем Дополнительные инструменты (в английском меню — More tools), а потом Инструменты разработчика (Developer tools).

Открыв панель инструментов разработчика, давайте приостановим код на брейкпоинте:

Выберите вкладку Sources.
В Sources, в панели Page, выберите app.js (который мы создали чуть раньше).
В редакторе кода, кликните на номер строки let data =document.getElementById('name').value;

Управление интервалами выполнения кода

Поставив брейкпоинт, ми приостанавливаем исполнение функции на нем. Поэтому нам нужно будет продолжить построчное выполнение кода, чтобы изучить изменения нашей переменной.
В верхнем левом углу панели JavaScript Debugging находятся основные команды прогонки брейкпоинтов:

Первая кнопка, Resume script execution () продолжит выполнение кода до конца или до следующего брейкпоинта.

Давайте введем hello world в поле ввода. В строку добавится data = “hello world”. Теперь давайте кликнем на кнопку Step over next function call ().

Выбранная строка с брейкпоинтом будет выполнена и дебаггер выберет следующую. Откройте вкладку Scope чтобы посмотреть значение переменной data. Оно изменилось на “hello world”, которое мы ввели ранее и просто показывает значение нашей переменной на конкретной строке кода. Кликните Step over next function call еще раз чтобы выполнить выбранный метод и перейти на следующую строку.

Если обновить страницу, значение переменной out также обновится в DOM элементе. Чтобы посмотреть значение переменной, можно кликнуть на Expand () слева от нее. Если же еще раз кликнуть Step over next function call, то текст “hello world” еще раз добавится в dataSpan.

Более сложная отладка

Предположим, что мы выполняем функцию посложнее, которую точно не помешает отладить. К примеру, мы хотим, чтобы пользователи вводили числа через пробел. Функция затем будет обрабатывать и выводить эти числа, их сумму, и результат умножения.

Для этого мы обновим код app.js как на скриншоте выше. Обновляем страницу и приступаем непосредственно к дебаггингу.

Кликните 3 (номер строки of let data = document.getElementById('name').value;) чтобы поставить брейкпоинт.
Введите 23 24 е в строке ввода в браузере.
Кликните Step over next function call.

Как еще можно поставить брейкпоинты

В большинстве случаев, ваш код намного длиннее и, вполне возможно, конкатенирован в одну строку. К примеру, предположим, что у вас 1000 строк кода. В этом случае, ставить брейкпоинты, кликая на номера строк каждый раз, не кажется такой уж отличной идеей, не правда ли?

Для этого в DevTools есть классный инструмент для установки брейкпоинтов на разные типы интеракции с браузером. На панели JavaScript Debugging, кликните Event Listener Breakpoints чтобы посмотреть доступные категории.

Как вы видите, можно поставить брейкпоинт на событие Mouse > click (клик мышкой) в любом месте нашего кода. Это означает, что, если кликнуть Get Input Data, выполнение кода остановится на событии onclick. И не нужно вручную ничего добавлять.

Клик на Step over next function call будет последовательно вести нас через код, используемый чтобы обработать клики.

Используя Event Listener Breakpoints, можно поставить брейкпоинты на кучу разных типов событий, таких как Keyboard, Touch, и XHR.

Ключевое слово “debugger”

Если ввести debugger в любом месте кода, Chrome DevTools приостановит выполнение кода на этой строке и подсветит ее также, как и брейкпоинты. Можно использовать этот инструмент чтобы дебажить JavaScript в Chrome или других браузерах. Только не забудьте удалить его, когда закончите отладку.

Код на скриншоте выше остановится на строке, которая содержит ключевое слово debugger и автоматически запустит Chrome DevTools. По сути, это то же самое, что и поставить брейкпоинт на эту строку. Также выполнением кода можно управлять с помощью кнопок Step into next function call и Step over next function call.

Выжимка

В начале мы рассмотрели команды console.log() и window.alert() и поняли, что они не слишком удобны. Нужно было их часто использовать по всему коду, что могло сделать код «тяжелее» и медленнее, если бы мы забыли их удалить перед коммитом.

Когда количество строк растет, Chrome Developer Tools намного более эффективен для отлова багов и оценки работы в целом.

Дебажим Angular

Легче всего отладить код Angular — использовать Visual Studio Code (VS Code). Чтобы начать дебаггинг, вам нужно будет установить расширение Debugger для Chrome:

Запустите проект на VS Code и откройте вкладку Extensions. Или нажмите Ctrl+Shift+X на клаве.
В строке поиска введите Chrome.
Выберите Debugger for Chrome и кликните Install.
После того как установите расширение, появится кнопка Reload. Кликните ее, чтобы завершить инсталляцию и активировать Debugger.

Настраиваем дебаггер

Для начала, нам нужно будет настроить дебаггер:

1. С File Explorer перейдите на Debug вкладку.
Также можно использовать для этого Ctrl+Shift+D.

2. Кликните на иконку Settings чтобы создать launch.json.
Это файл с настройками, который мы будем использовать.

3. С выпадающего меню Select Environment выберите Chrome.
Это создаст новую папку .vscode и файл launch.json для вашего проекта.

4. Запустите этот файл.

5. Чтобы использовать этот файл для наших целей, в методе url замените localhost порт с 8080 на 4200.

6. Сохраните изменения.

Вот как должен выглядеть файл:

7. Нажмите F5 или кликните кнопку Start Debugging чтобы запустить Debugger.

8. Запустите Chrome.

9. Чтобы приостановить выполнение кода на брейкпоинте, обновите страницу.

Чтобы последовательно просмотреть выполнение кода и как меняются переменные, используйте клавишу F10.

README

В расширении Debugger для Chrome есть множество дополнительных конфигураций, работа з source maps и устранений всяческих неполадок. Чтобы просмотреть их прямо в VS Code, кликните на расширение и выберите вкладку Details.

Отладка бекенда (Node.js)

Здесь вы узнаете как дебажить код на Node.js. Вот самые распространённые подходы:

• Используя Chrome DevTools
На даный момент, это наш любимый подход.

• Используя IDE-шки типаVisual Studio Code, Visual Studio, WebStorm, и т.д.

Для примеров мы будем использовать VS Code и Chrome DevTools.

Chrome и Node.js используют тот же JavaScript-движок, Google V8, и это значит, что для бекенда мы будем использовать те же инструменты, что и для фронта.

1. Запустите свой проект в VS Code.

2. Перейдите на вкладку Console.

3. Введите команду npm start --inspect и нажмите Enter.

4. Проигнорируйте предлагаемый “chrome-devtools://…” URL (существует метод получше).

5. Запустите Chrome и введите “about:inspect”.

Это перенаправит вас на вкладку Devices на DevTools.

6. Кликните линк Open dedicated DevTools for Node.

Процесс отладки такой же, как и для фронтенда, то есть с использованием брейкпоинтов. На самом деле, очень удобно то, что не нужно переключаться на IDE. Таким образом, можно дебажить и фронт- и бекенд на одном интерфейсе.

Спасибо за чтение и надеемся, что вам понравился этот пост. Подписывайтесь на обновления — у нас в рукавах еще полно полезностей :-)

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

Казалось бы — да что тут рассказывать? Всё же очевидно. Но вопрос этот мне задают с завидной частотой. Да и мне есть, что рассказать.

Приведу конкретные примеры и расскажу, как я их решаю.

Видим цель, не видим препятствий

JavaScript вывалил ошибку? Замечательно! Нет, это конечно плохо, но гораздо лучше, чем если бы он промолчал (да, бывает и такое!) в случае ошибки.

Наша цель — понять, что же, чёрт побери, произошло? Но сначала — ~~рекламная пауза~~ лирическое отступление: средства JavaScript Debug'а в основных браузерах.

Debuggers

А вот немного «вкусностей» — conditional breakpoints (правый клик по «бряке»):

То есть заводим глобальную переменную (к примеру) allowBreakpoints и «бряки» будут срабатывать только тогда, когда мы сами того захотим.
К сожалению, работает не везде, поэтому я это обычно не использую.

Как «тормознуть» поток

Ключевое слово debugger . Увидав такое в коде, любой уважающий себя JS-debugger остановит поток JavaScript и покажет нам место остановки

А вот вариант с условной остановкой:

* This source code was highlighted with Source Code Highlighter .

Мне так нравится гораздо больше, чем ставить «бряку»: так я пишу код и дебажу его по сути в одном месте, а не в двух.

Debug через alert()

Это наименее информативный debug, который к тому же останавливает поток JavaScript. Да к тому же модальный по отношению к браузеру. Забудьте, что он вообще существует.

Особенность breakpoint'ов

Рассмотренные варианты все, как один, тормозят поток JavaScript. Это плохо!

Почему? Если в момент остановки скрипта у вас был запущен AJAX-запрос или Timeout, и ответ не успел вернутся — он может уже не вернутся никогда. Согласитесь, в современных web-проектах этого добра хватает. Поэтому в момент «экстренной остановки» скрипта мы уже не сможем адекватно debug'ать дальше — часть логики будет безвозвратно утеряна.

Поэтому я стараюсь избегать на практике debug с остановкой.

«Debugging JavaScript with breakpoints is bad, mmkay?» © Mr. Mackey, South Park

Однако: breakpoint есть breakpoint, и если вы исследуете ну очень запущенный баг — тут без остановки не обойтись (надо будет сделать watch текущим переменным и т.д.)

«Правильный» debug

Коротко: хороший debug — через logging. Так я в основном и работаю — в нужном месте в нужное время срабатывает console.log(. ) .

Да, насчёт console.log — впервые этот метод увидел мир, насколько я помню, вместе с Firebug. Никакой это не стандарт и не факт, что оно заработает в IE6. Однако современные браузеры вводят logging именно как console.log . Это так, к сведению. И если в продакшн попадёт код с console.log(. ) — будьте на чеку, может поломаться! Так что может быть стоит переопределить у себя в коде объект console , так, на всякий пожарный.

Если же в целевом браузере нет console.log , а хочется — попробуйте Firebug Lite или Blackbird, может понравится ;)

Пример №1

JavaScript показал ошибку. Надо понять — что к чему.
Включаем в debugger'е режим «Break On Error»:

Воспроизводим ошибку снова. JavaScript останавливается. Видим место ошибки, делаем watch и точно определяем, в чём же дело.

Пример №2

CASE:
JavaScript не показал ошибку. Но вы знаете, что она есть (как суслик). Да, такое иногда бывает.

CASE:
Надо просто продебажить некий код. Скажем, посмотреть, что происходит по нажатию кнопки или после AJAX-загрузки данных.

Тут сложней — надо найти, с чего начать.

Немного искусства

Самое главное — разбираться в средстве разработки. Будь то jQuery, или ExtJS, или Mootools, или вообще свой собственный framework — нужно понимать, как создаётся кнопка, как «навешивается» обработчик события, как данные ходят в AJAX, как попадают в grid, как работает TinyMCE RTE, как, как, как… Если нет понимания задачи — не получится её решить!
Используем Inspect нашего debugger'а (если нет Inspect'а — используйте всё тот же Firebug Lite):
1. Находим нужный элемент HTML (например, кнопку)
2. Ищем ближайший от него элементс осмысленным ID (н-р: а уже не подходит) вверх по иерархии (это может быть и сама кнопка, а может быть DIV четырмя уровнями выше)
// условная остановка
if (allowBreakpoints == true )
debugger;

// или просто
debugger;

* This source code was highlighted with Source Code Highlighter .

Так, значит место в коде нашли, бряку поставили. Если не хочется (или просто нельзя) изменять исходный код — можно вместо ключевого слова debugger поставить brakepoint в средстве отладки.

Пример №3

Тот же случай: надо продебажить некий код. Скажем, посмотреть, что происходит по нажатию кнопки или после AJAX-загрузки данных. Но в этот раз мы не можем тормозить поток JavaScript по описанным мной причинам.
1. Ищем нужное место тем же способом
2. Вместо debugger пишем console.log(variable_to_watch)
CASE UNO

variable_to_watch — объект, который изменился с момента вывода в консоль. А хочется увидить его состояние именно на момент вызова.

Тут надо использовать не console.log(variable_to_watch) , а console.dir(variable_to_watch)

CASE DUO

Нужно не просто увидеть текущее значение variable_to_watch , но ещё и поэкспериментировать с ним (например, хочется вызвать его метод):

// пусть хочется получить доступ к объекту obj
if (debugEnabled)
console.log(window.temp_var = obj);

* This source code was highlighted with Source Code Highlighter .

Таким образом мы не только увидим вывод в консоли, но и получим доступ к объекту через глобальную ссылку на него: window.temp_var .

Открываем Firebug->Console и вызваем метод: temp_var.objMethod() .

Нет консоли? Пишем в адресной строке: javascript:alert(temp_var.objMethod()); void 0;

Пример №4

Ещё один пример. Возможно, немного странный. Хочется продебажить метод 3d-party-framework'а (например, ExtJS), но вот беда — нельзя тормозить JavaScript и нет доступа к исходному коду (правда странный пример? :)

Что же делать? Я делаю так:

Создаём файл с патчем: my-ext-patch.js, и подключаем его после ext-all.js
Внутри пишем что-то вроде:

( function () var _backup = Ext.form.Form.render; // Резервируем метод рендера формы. -- Ваш Кэп ;)

Ext.form.Form.render = function (container) < // Wrap'им метод
// А вот и дебаг
console.log(container);

// Возможны варианты:
// console.dir(container);
// console.log(window.t = container);
// debugger;

// Выполняем начальный метод
return _backup.apply( this , arguments);
>
>)();

* This source code was highlighted with Source Code Highlighter .

Извращение? Возможно. Но мне нравится >:)

Эпилог

Вот так можно дебажить ~~«этот $%*!%$!»~~ JavaScript. Важно сосредоточиться на первых трёх примерах.

Читайте также: