MutationObserverの変更記録モデルとマイクロタスク配送

なぜ同期通知ではなくレコードの束ねなのか

DOMの変更を監視したいとき、素朴な発想は「ノードが変わるたびにコールバックを呼ぶ」同期通知です。実際、初期のDOMにはこれを行う Mutation Events（DOMNodeInserted など）がありました。しかしこの設計は深刻な欠陥を抱え、現在は非推奨です。

問題の核心は、変更の途中で外部コードに制御が渡ることにあります。1回の appendChild のような操作の最中にイベントが同期発火し、そのハンドラがさらにDOMを書き換えると、進行中の変更と新しい変更が入れ子になります。ツリーの整合性を保つのが極端に難しくなり（再入問題）、1ノードの挿入が連鎖イベントを誘発して性能も崩れます。ブラウザ実装側でも、あらゆる変更点に同期ディスパッチを挿し込むコストが重くのしかかりました。

MutationObserver はこの反省から、変更をその場で通知しない設計に切り替えました。変更は MutationRecord という記録レコードに蓄えられ、複数の変更がまとまった単位で、後から非同期に配送されます。コールバックが走る時点ではDOM操作の連鎖はすでに完了しているため、観測側は常に一貫した確定状態のツリーを見ます。

変更記録モデル：MutationRecordへの蓄積

MutationObserver を作り observe(target, options) を呼ぶと、ターゲットノードに観測対象（registered observer）が登録されます。以降、DOMに変更が起きるたびに、その変更を表す MutationRecord が、影響を受けるObserverの**記録キュー（record queue）**に積まれます。レコードは変更の種類ごとに次の情報を持ちます。

type            : "childList" | "attributes" | "characterData"
target          : 変更が起きたノード
addedNodes      : 追加されたノード（childList時、staticなNodeList）
removedNodes    : 削除されたノード（childList時）
previousSibling : 追加/削除位置の直前の兄弟
nextSibling     : 追加/削除位置の直後の兄弟
attributeName   : 変わった属性名（attributes時）
oldValue        : 変更前の値（対応オプション指定時のみ）

重要なのは、レコードが変更の差分を表す点です。childList なら追加・削除ノードの集合、attributes なら変わった属性、characterData ならテキストの変化です。attributeOldValue / characterDataOldValue を有効にしない限り oldValue は null のままで、無駄な旧値保持を省きます。subtree: true を付けると、ターゲット自身だけでなく全子孫の変更も同じObserverに集約されます（DOMツリーの内部表現 の親子・兄弟リンクを辿る形で観測範囲が決まります）。

マイクロタスク配送：いつ、どう呼ばれるか

レコードが積まれただけではコールバックは走りません。仕様は「Observerをマイクロタスクとしてキューする（queue a mutation observer microtask）」という専用の手続きを定義します。あるObserverに初めてレコードが積まれた回に、まだスケジュール済みでなければ、通知用のマイクロタスクが1つ予約されます。同一バッチ内で何度変更が起きても、マイクロタスクは重複してキューされません。

そのマイクロタスクが実行されると、各Observerについて「記録キューを空にして取り出し、その配列を引数にコールバックを1回呼ぶ」という処理が走ります。つまりコールバックは、その間に溜まった全レコードをまとめて受け取ります。

const observer = new MutationObserver((records, obs) => {
  // records は溜まった MutationRecord の配列。
  // 1回の DOM 操作群がまとめて 1 配送で届く。
  for (const r of records) {
    if (r.type === "childList") {
      handleChildList(r.addedNodes, r.removedNodes);
    }
  }
});

observer.observe(node, { childList: true, subtree: true });

マイクロタスクである帰結は明確です。配送は現在のタスク（またはマイクロタスク）が終わった直後、マイクロタスクキューを排出する段で走り、レンダリング更新より前に完了します。setTimeout（タスク）より早く、しかし同期コールバックより遅い、という中間の位置取りです。連続するDOM操作を1つの同期コードブロックで行えば、それらは1回の配送にまとまります。この順序関係は イベントループの内部構造 のタスク／マイクロタスク／レンダリングの並びそのものです。

takeRecords と disconnect：保留レコードの制御

配送を待たずに保留中のレコードを同期的に引き出したいことがあります。takeRecords() は記録キューを空にして、溜まっていたレコード配列をその場で返します。これによりキューが空になるため、予約済みのマイクロタスクが後で走ってもコールバックには何も渡りません（あるいは新たな変更分だけが渡ります）。

// disconnect の直前に取りこぼしを回収する典型例
const pending = observer.takeRecords();
observer.disconnect();
processRecords(pending); // 配送を待たずに今すぐ処理

disconnect() は全ターゲットの registered observer を解除し、保留中のレコードもすべて破棄します。つまり disconnect 後にコールバックが残レコードで呼ばれることはありません。取りこぼしを避けたいなら、上のように disconnect の前に takeRecords() で回収します。

レコードの粒度と観測範囲の注意点

childList のレコードは直接の子の追加・削除を記録します。subtree: true でも、記録される target は変更が直接起きた親ノードであり、addedNodes / removedNodes はそのとき動いたノードのみです。深い部分木をまるごと挿入しても、内部の各ノードが個別レコードになるわけではなく、部分木の根を addedNodes に持つ1レコードとして届きます。削除されたノードを removedNodes から得たあと、それを再び document から辿ろうとしても、すでにツリーから外れているため見つからない点にも注意します。

属性監視では attributeFilter で対象属性を絞れます。フィルタを与えると、列挙した属性以外の変更はレコード化されず、不要な通知を抑えられます。テキスト変更（characterData）は Text ノードなどのデータの変化を捉えるもので、要素の追加・削除とは別系統です。

なお MutationObserver は shadow ツリー内のノードも、そのツリーのホストではなくshadow root 側を直接 observe すれば監視できます。light DOM 側のObserverは shadow 境界を越えて子孫を観測しません（境界とツリー合成の原理は Shadow DOMのカプセル化 を参照）。

まとめ