`<wa-select>` のクリアボタンが初期値設定時に機能しないバグを修正

<wa-select> コンポーネントで初期値が設定されている場合にクリアボタンが機能しないバグが修正されました。handleClearClick に2つのフラグ設定を追加するだけのシンプルな修正ですが、コンポーネントの状態管理の設計を端的に示しています。

背景

<wa-select> はクリア可能な選択コンポーネントですが、初期値が設定された状態ではクリア操作が正しく機能しないバグが存在していました。ユーザーが明示的にクリアボタンをクリックしても選択状態がリセットされない、という動作上の問題です。

根本原因は、クリア処理の実行前に hasInteracted と valueHasChanged という2つの状態フラグが更新されていなかったことにあります。これらのフラグはコンポーネントの「ユーザー操作済み」と「値変更済み」の状態をそれぞれ追跡するものであり、クリア後の値反映処理においてこれらのフラグが参照されていたと考えられます。

技術的な変更

handleClearClick メソッドの冒頭に、2つのフラグを true に設定する処理が追加されました。

変更前:

private handleClearClick(event: MouseEvent) {
  event.stopPropagation();

  if (this.value !== null) {
    this.selectionOrder.clear();
    this.setSelectedOptions([]);

変更後:

private handleClearClick(event: MouseEvent) {
  event.stopPropagation();

  this.hasInteracted = true;
  this.valueHasChanged = true;

  if (this.value !== null) {
    this.selectionOrder.clear();
    this.setSelectedOptions([]);

追加されたのはわずか2行ですが、その位置が重要です。value !== null の条件チェックより前、つまりクリアが実際に行われるかどうかに関わらず、クリアボタンがクリックされた時点でフラグを立てています。

設計判断

状態フラグを条件分岐の外側に置く という設計選択に注目できます。

hasInteracted と valueHasChanged はそれぞれ「ユーザーがコンポーネントに触れたか」「値が変化したか」を示すフラグです。初期値が設定されている場合、コンポーネントは「ユーザーがまだ操作していない」状態にあり、これらのフラグが false のままでした。クリアボタンのクリックは明確なユーザー操作であるため、クリア後の値変更処理が「変更なし」と判断されてしまい、選択状態のリセットが反映されなかったと推測されます。

フラグの設定を if (this.value !== null) ブロックの外側に置いた点は、「クリアボタンをクリックした」という意図そのものを状態として記録するという設計思想を反映しています。実際に値が変わったかどうかとは独立して、ユーザーの操作意図を先に確定させることで、後続の処理が正しく動作するようになっています。

まとめ

2行の追加という最小限の変更で、初期値設定時のクリア不具合を解消したこのPRは、フォームコンポーネントにおける「操作状態の追跡」が値の反映フローに深く関わっていることを示しています。状態フラグの更新タイミングの設計が、コンポーネントの正しい動作に直結する好例です。