B.B Enterprise BLOG

JavaScriptの要素取得メソッドを使う時には取得できなかった時の想定も必要だよねというお話

いきなり本題

例えば特定の要素を取得し、その要素をクリックしたら何か処理できるようにする場合を想定して、下記のようにコードをまとめるとします。

HTML

<div id="targetElement">ほげ</div>

JavaScript

const targetElement = document.getElementById("targetElement");
targetElement.addEventListener("click", () => {
    // 何か処理
});

上記のように記載し実行した場合、HTML側で「id=”targetElement”」が付与されている要素がある前提で、はじめて動作する処理となっています。

このページを公開直後は、クライアントの希望にも沿った動作となっているため、何ら問題は無いとも考えられますが、公開後の時間経過とともに、このページに対して内容の変更を求められるケースは多々考えられると思います。

例えば、クライアントから「この部分(id=”targetElement”がついた要素)は必要がなくなったため、削除して公開しなおしたい」と新たに要望もあることでしょう。

その要望に対して、仮にJS側は編集せずにHTML側だけを修正して再公開をしてしまった場合、下記のようなエラーがブラウザのコンソール上に表示されてしまいます。

Uncaught TypeError: Cannot read properties of null (reading ‘addEventListener’)

このような状況となると、エラーが出た行で処理が止まるため、その記述以下に別の処理が書いてあったとしても実行されません。

そのため、対策として要素取得の際には、下記のように記載することで、要素の取得ができなかった場合もエラーは出さず、それより下の行の処理を実行できるようになります。

JavaScript

// 期待する要素の取得ができず、nullが格納される
const targetElement = document.getElementById("targetElemenat");
// nullはFalsyな値とみなされるため、if文内の処理は実行されない
if (targetElement) {
    targetElement.addEventListener("click", () => {
            // 何か処理
    });
}
// 上記処理とは関係なく、下記は実行される
alert("ほげ");

最後に

本来であればHTML側にあわせて、JSファイル内の不要な処理も削除することは必要ですが、作業者が変わり全容把握ができていない中での作業であったり、短期間に何度も同じページの更新が入るようなケースで、一部ファイルの編集漏れが発生した場合等にもこのような想定を踏まえた記述は有効だと考えられます。忙しい時ほどこういった部分は忘れずに対応していきたいと、自戒の意味も込めてまとめてみました。

参考

MDN – Truthy
MDN – Falsy