デベロッパーツール の続きです。JSコードのデバッグ、前回は調べたい処理の該当コードを特定する方法をまとめました。今回は特定したコードから調べたい箇所で処理を止めるブレークポイント設定編です。ステップ実行のメニューやサイドパネルの項目もまとめました。それでは行きましょう！
【目次】
※参考：【デベロッパーツール】JSコードのデバッグ（前編：コード特定編） - クモのようにコツコツと
※参考：Web開発環境の記事まとめ
qiita.com
ブレークポイント
前回のクリックイベントでブレークポイントを設定してみる。
See the Pen fetch api 01_debugSample by イイダリョウ (@i_ryo) on CodePen.
前回のような方法でJSの該当コードを特定した状態（「Sources」パネル）にて。
textChange()関数の中を調べたい場合
左側の行番号のところでtextChange()関数の部分をクリックすると…
textChange()関数の頭ではなく関数の中（1行目）に印が付く。この印が「ブレークポイント」！*1
この状態でイベントを発生させる。「押すが良い」を押すとプレビュー画面がモーダル状態（グレー色）になる。
これがブレークポイントによって処理がブレークしている状態！
処理が途中で止まっているため、文字がまだ「押すが良い」のままになっている。
ステップ実行のメニュー
さて、処理をブレークして何が嬉しいの？という話になるが、この先の処理を1行ずつ進めて、処理が途中でどう変化していくのかを調べることができる。これを「ステップ実行」という。ステップ実行のメニューを見ていく。
まず、画面の上にあるツールボタン
| No. | 名前 | 備考 |
|---|---|---|
| ① | Resume script execution | 次のブレークポイントに進む（ブレークポイントが1つの場合はブレーク解除） |
| ② | Step over next function call | ステップオーバー（コールバック関数を無視する） |
①はブレークポイント単位で進むがブレークポイントが一つしかない場合はブレークを終了する。
②はステップオーバーと言って、1行ごとに処理を進める。ただし、別の場所の関数（コールバック関数）を読み込んでいる場合、その関数には進まない。
この二つの処理はよく使うので目立つ場所に配置されている。
もう一つ、デベロッパーツール のサイドバーにもステップ実行のメニューがある。
| No. | 名前 | 備考 |
|---|---|---|
| ① | Resume script execution | 次のブレークポイントに進む（ブレークポイントが1つの場合はブレーク解除） |
| ② | Step over next function call | ステップオーバー（コールバック関数を無視する） |
| ③ | Step into next function call | ステップイン（コールバック関数を含む） |
| ④ | Step out of current function | ステップアウト（関数の外に出る） |
| ⑤ | Step | ステップ実行（②と同じっぽい？） |
| ⑥ | Deactivate breakpoints | ブレークポイントの無効化 |
| ⑦ | Pause on exceptions | 例外処理（エラー）のブレークポイント |
よく使うのは左側の①〜④の部分。
③ステップインはコールバック関数も含んで1行ずつ実行する。ライブラリやフレームワークを利用している時はその元のコードまで見にいく。
コード全体の動きを理解したい場合は③ステップイン、調べたい関数が特定できている場合は②ステップアウト、という使い分けになる。
ステップ実行画面の構成
先ほどのブレーク状態の画面
左のソースコードで行番号のところにブレークポイントが打たれている。
右のサイドバーにはステップ実行のメニュー。その下で値の詳細を調べたり設定できる。
| 名前 | 備考 |
|---|---|
| Watch | ここに指定した特定の変数の状態を監視できる |
| Call Stack | 関数のアクティブな処理が実行順に並んでいる（前に戻れる） |
| Scope | ステップ実行時の変数の値の状態が調べられる |
| Breakpoints | ソースのブレークポイントが処理されたらブレーク |
| XHR/Fetch Breakpoints | XHRリクエストの指定した文字列が会ったらブレーク |
| DOM Breakpoints | Domに指定した変更があったらブレーク |
| Global Listeners | グローバルオブジェクトのイベントリスナー？ |
| Event Lintner Breakpoints | 指定したイベントが発生したらブレーク |
上に行くほどよく使う。したの方はブレーク設定で、ここのチェックを付けたり外したりして設定、解除ができる。
ブレイクしない＝関数が実行されない
ちなみに、ブレークポイントを打ったにも関わらず、画面がブレークしない場合は、その関数が実行されていないことを意味する。
例えばこちらの例。
See the Pen fetch api 01_debugSample2 by イイダリョウ (@i_ryo) on CodePen.
「押すが良い」を押しても何も実行されない。
先ほどと同じくtextChange()関数の行にブレークポイントを実行してみる。
「押すが良い」を押しても、画面がブレーク状態にならない！
「Console」タブを見るとエラーメッセージが表示されている。
Uncaught ReferenceError: textCange is not defined
「キャッチされていないReferenceError：textCangeが定義されていません」とある。
エラーメッセージにあるファイル名&行数のリンクをクリックすると
エラーが起きている箇所に移動する。
textCangeが定義されていません。つまりこのDOMのイベント属性の中の値textCange()がタイプミスでtextChange()関数と異なっているため、DOMと関数が紐づかない状態になっていた。
このように、目的の処理が起こらない場合に、ブレークポイントを打って、ブレークするかしないかで関数全体が動いているかを確認することができる。
最後に
すみません、またまた長くなりそうなので、回を分けます。
コードを特定して、画面をブレークして、次はいよいよステップ実行をしながらコードをデバッグしていきます。
それではまた！
※参考：つづき書きました！
www.i-ryo.com
※参考：Web開発環境の記事まとめ
qiita.com
*1:基本的には調べたい箇所の次の1行目にブレークポイントを付ける
