はじめに
kintoneカスタマイズのデバッグ、できていますか?
「はじめようシリーズのカスタマイズはできたけど、自分で実装するとカスタマイズがうまく動作しなくてどこをどう修正したらいいか分からない」という声を聞くことがあります。
"脱はじめようシリーズ"を目指すみなさんに向けて、本記事ではkintoneカスタマイズの基本的なデバッグの流れを紹介します。
kintoneカスタマイズのデバッグについては、
動かない?そんな時はデバッグをしてみよう!入門編
も合わせて目を通してみてください。
デバッグの流れはさまざまな原因によって異なるため、本記事で紹介しているエラー対処の流れがあらゆるパターンに当てはまるわけではありません。
カスタマイズのデバッグにはGoogle Chrome(バージョン:104.0.5112.102)を利用しています。
基本的なデバッグの流れ
kintoneカスタマイズの基本的なデバッグの流れは以下です。
- カスタマイズを適用して、開発者ツールのコンソール画面を開く。
- コンソール画面を開いて、エラーが出ているか確認する。
- エラーが出ている場合、エラーの内容から原因調査をする。
- エラーが出ていない場合、起きている現象から原因調査をする。
この流れに沿ってカスタマイズが動作しない原因を探しにいきましょう。
1. カスタマイズを適用して、開発者ツールのコンソール画面を開く
カスタマイズを適用した後に意図した動作ができていない場合は、まずブラウザー開発者ツールのコンソール画面を開きましょう。
Chrome開発者ツールのコンソール画面は、以下の操作で開くことができます。
- Google Chrome
Ctrl + Shift + I
キーを同時に押下(MacはCommand + Option + I
)- コンソール(英語の場合はConsole)タブをクリック
その他ブラウザーの開発者ツールのコンソール画面の開き方については、以下になります。
-
Firefox
Ctrl + Shift + I
を同時に押下(MacはCommand + Option + I
)- コンソールタブをクリック
-
Microsoft Edge
F12
を押下- コンソールタブをクリック
2. コンソール画面を開いて、エラーが出ているか確認する
次に、コンソール画面にエラーが出ている時は、エラーの内容を読み取ってその原因を調査します。
一方、コンソール画面にエラーが出ていない時は、発生している現象の内容を基にうまく動作しない原因を調査します。
本記事では、3つのエラーパターンでデバッグの流れの例を紹介しているので、気になるエラーパターンを確認してみてください。
3. エラーが出ている場合、エラーの内容から原因調査をする
コンソール画面に出力されているエラーの内容をもとに以下のいずれか、もしくは複数の方法を組み合わせて調査します。
各調査方法の具体的なやり方についてはリンク先を参照してください。
- A. ブレイクポイント機能を利用して、調査する方法
-
B.
console.log(record);
をソースコードに入れて調査する方法 -
C.
kintone.app.record.get();
をコンソール画面に入力して調査する方法 -
D.
debugger;
をソースコードに入れて調査する方法
4. エラーが出ていない場合、起きている現象から原因調査をする
コンソール画面にエラーが出力されていない場合は、起きている現象を把握したうえで、主に以下をチェックします。
- カスタマイズが正しく適用されているか。
- kintone.events.onでセットしたイベントタイプが間違っていないか。
- 即時関数の書き方ができているか。
上記以外にも「kintone.events.onのイベントハンドラー内で、return eventしているか」など、ケースに応じていろんなチェックポイントが考えられます。
ここで挙げたチェックポイントを確認しても正常に動作しない場合は、他に何か間違っている点があるかもしれません。
根気強く、考えつく限りの可能性をチェックしてみる必要があります。
よくあるエラー
1. 'Cannot read property 'value' of undefined' エラーの場合
実現したいカスタマイズ
アプリストアにある「案件管理」アプリをカスタマイズして、会社名というフィールド名のフィールドの値をアラートで出力したい。
適用したカスタマイズ
|
|
開発者ツールのコンソール画面
エラーの内容は以下のとおりです。
|
|
デバッグの流れ
コンソール画面に表示されるエラーを確認すると、value
がundefined
になっていることを確認できます。
ここでは、value
がundefined
になっている原因調査のため、カスタマイズのソースコードを確認します。
開発者ツールのSourcesタブから、適用したカスタマイズの中身を確認できます。
コンソール画面に出力されているエラーの2行目at download.do?app=〜
をクリックすると、エラーが発生したソースコードに直接遷移できます。
コンソール画面に出力されているエラー内容とカスタマイズ内容を照らし合わせると、valueの記載があるのは14行目だけです。
そのため、14行目に何か問題がありそうだと見当をつけることができます。
さらに、14行目のvalueは変数record
の中の「会社名」というフィールドコードのフィールドの値(value)です。
上記の理由から、以下2点が原因として考えられると推測しました。
- 変数
record
の中身がない。 - 「会社名」というフィールドコードのフィールドが存在しない。
ここからは以下の4パターンの調査方法のいずれかを利用して、原因調査を進めます。
- A. ブレイクポイント機能を利用して、調査する方法
- B.
console.log(record);
をソースコードに入れて調査する方法 - C.
kintone.app.record.get();
をコンソール画面に入力して調査する方法 - D.
debugger;
をソースコードに入れて調査する方法
A. ブレイクポイント機能を利用して、調査する方法
ブラウザー開発者ツールのSourcesタブでブレイクポイント機能を使うと、カスタマイズの読み込みを好きなところで一時的に停止できます。
また、ソースコード中の変数をマウスオーバーすることで、変数の中に何が格納されているかを確認できます。
そこで、この機能を使って以下のGIFのように14行目にブレイクポイントを入れて再度読み込みます。
読み込んだら、変数record
をマウスオーバーしrecord
の中身を確認します。
なお、ブレイクポイントは複数ヵ所設定できるので、変数が複数存在するカスタマイズでは、怪しいと思われるすべての行にブレイクポイントを入れて1箇所ずつ確認します。
上のGIFから、変数record
の中身はあるもののrecord
の中に「会社名」というフィールドコードのフィールドは存在しないことが分かります。
そこで、アプリ管理のフォーム設定画面を確認すると、会社名フィールドのフィールドコードは「文字列1行」だと判明しました。
そのため、カスタマイズ10行目の「会社名」の記述を「文字列1行」に書き換える必要があります。
コードを書き換えて再度レコードの詳細画面を開いてみると、想定どおりアラート画面が表示されており無事に意図した動作を確認できました。
B. console.log(record);
をソースコードに入れて調査する方法
「変数record
の中身がない」もしくは「会社名というフィールドコードのフィールドが存在しない」かどうかを確認するために、カスタマイズの14行目に console.log(record);
を挿入して実行してみます。
|
|
このカスタマイズを実行し、開発者ツールのConsoleタブを確認します。
コンソールの画面にはさきほどのエラーと一緒に、変数record
の中身が出力されているのを確認できます。
コンソールに出力されている変数record
の中身を確認すると、record
の中に「会社名」というフィールドは存在しないことが分かります。
そのため、会社名フィールドのフィールドコードが間違っていると推測できます。
あとは、Aと同じ流れです。
C. kintone.app.record.get();
をコンソール画面に入力して調査する方法
「変数record
の中身がない」もしくは「会社名というフィールドコードのフィールドが存在しない」かどうかを確認します。
開発者ツールのConsoleタブでkintone.app.record.get();
を実行して、record
の中身を確認します。
具体的な使い方のイメージは、 Google Chrome開発者ツールのTips集 -kintone開発特化編- で詳しく解説しています。
コンソール画面で実行すると、Bと同様にrecord
の中身を確認できます。
ぜひご自身で確認してみてください。
D. debugger;
をソースコードに入れて調査する方法
カスタマイズの実行を任意の場所で停止する方法として、Aで紹介したブレイクポイントを使う方法以外にもソースコードの中にdebugger;
を入れる方法があります。
|
|
上のように14行目にdebugger;
と記述したソースコードをkintoneに読み込ませて実行すると、debugger;
の記述があるところでカスタマイズの実行を停止できます。
debuggerの詳細については debugger(外部サイト) を参照ください。
2. 'POST {URL} 403 (Forbidden)' エラーの場合
実現したいカスタマイズ
「案件管理」アプリのレコードを閲覧したユーザーの閲覧ログを「閲覧履歴」アプリにレコードとして残したい。
適用したカスタマイズ
|
|
開発者ツールのコンソール画面
エラーの内容は以下のとおりです。
|
|
デバッグの流れ
コンソール画面を見ると、以下2点を確認できます。
- record.jsonのPOSTリクエストがエラーコード403で出力されていること
- カスタマイズ28行目に記載している
console.log('失敗');
が出力されていること
ひとまずconsole.log('成功');
とconsole.log('失敗');
それぞれの1行下に、console.log(resp);
を追記してresp
の中身を確認します。
|
|
追記して再度読み込んでみると、コンソール画面にresp
の内容が出力されます。
message
に「権限がありません」と出力されるので、POST先アプリのアクセス権設定を確認します。
「閲覧履歴」アプリのアクセス権を確認したところ、アプリのアクセス権で「レコード追加」が設定されていないとわかります。
そこで、レコード追加にチェックを入れて保存します。
再度読み込んで実行すると、まだうまく動作していないようです。
以下のエラーがコンソール画面に出力されています。
|
|
message
に「入力内容が正しくありません」とあるので、errors
の中を見てみます。
record.閲覧アプリID.value
のmessages
が「必須です」と出力されています。
つまり、フィールドコード「閲覧アプリID」の値(value)をPOSTリクエストのbody
に正しくセットできていないことがわかります。
そこでカスタマイズの内容と「閲覧アプリID」フィールドのフィールドコードを再度確認します。
カスタマイズが正しいフィールドコードになっていないことがわかったので、アプリの設定に合わせて「閲覧アプリID」に修正します。
- カスタマイズに記載した「閲覧アプリID」フィールドのフィールドコード:
閲覧アプリid
- アプリに設定した「閲覧アプリID」フィールドのフィールドコード:
閲覧アプリID
再度読み込むと閲覧ログが「閲覧履歴」アプリに登録され、意図した動作を確認できました。
3. コンソールにエラーが出ていない場合
実現したいカスタマイズ
「案件管理」アプリのレコードを閲覧したユーザーの閲覧ログを「閲覧履歴」アプリにレコードとして残したい。
2. 'POST {URL} 403 (Forbidden)' エラーの場合
と同じカスタマイズです。
適用したカスタマイズ
|
|
開発者ツールのコンソール画面
出力なし
デバッグの流れ
このカスタマイズを適用しても、「閲覧履歴」アプリにレコードが追加されておらずコンソール画面にも何も出力されていません。
開発者ツールのSourcesタブで、カスタマイズが適用されているか確認してみると、カスタマイズは適用されているようです。
カスタマイズは適用されているようなので、カスタマイズが実行されているかを確認するためにブレイクポイントをセットします。
再度読み込みしてみたところ、なぜかブレイクポイントで処理が止まりません。
このことから、何らかの原因でカスタマイズが実行されていないと推測されます。
原因の可能性として次の2点を考えました。
- kintone.events.onのイベントタイプが間違っている。
- 即時関数の書き方になっていない。
それぞれを確かめてみます。
kintone.events.on
のイベントではレコード詳細画面の表示後イベントを実行してほしいので、
レコード詳細画面の表示後イベント
のapp.record.detail.show
を設定します。
カスタマイズを確認すると同じイベントタイプが記載されているので、イベントタイプは問題なさそうです。
では、次に即時関数の書き方になっているか確認してみます。
カスタマイズを確認すると、正しい即時関数の書き方になっていませんでした。
33行目に以下のように()
をつけることで、意図した動作を確認できました。
最初に適用したカスタマイズをよく確認すると、以下のような形になっています。
|
|
この書き方は即時関数の書き方になっておらず、再読み込みしてもカスタマイズは実行されません。
そのため、ブレイクポイントをセットしても処理が止まりませんでした。
即時関数について詳しく知りたい方は IIFE(即時実行関数式)(外部サイト) を参照してください。
まとめ
カスタマイズが動作しない原因はさまざまです。
実際のデバッグケースは、この記事で取り上げた内容より複雑でエラーの原因を探し出すのはたいへんだと思います。
しかし、この記事で紹介したデバッグの流れや考え方を参考にトライアンドエラーを繰り返していけば、少しずつエラー原因へ近付けるようになるはずです。
ぜひ、この記事に書いている方法や考え方を身につけてデバッグ力を磨いてください!
Chromeの開発者ツールを利用したJavaScriptカスタマイズのデバッグ方法についてもっと知りたい方は、公式サイト DevTools(外部サイト) の記事も参考にしてみてください。
このTipsは、2022年9月版kintoneで動作を確認しています。